Log generation method and device and computer equipment

Abstract

The invention discloses a log generation method and device and computer equipment, and the method comprises the steps: weaving a tangent plane for a target service interface containing a tangent point identifier in a business application; intercepting a service request sent by an upstream application based on a section, and generating a request log for the service request in a first format; filtering downstream application response data which is returned by the downstream application and is related to the service request based on a filter, and generating a simulation log based on a filtering result; and intercepting service response data for the service request based on the aspect, and generating a response log in a first format based on the service response data. By implementing the method and the device, the request log and the response log in a uniform format can be generated by combining the preset section on the premise of not invading a business core code, so that log generation and business logic decoupling are realized.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a log generation method, device and computer equipment. Background Art

[0002] Logs are technical data used to record the running status of programs. Generally speaking, their contents include user operations made by the program in response to user requests, whether there are any abnormalities in the running environment, data changes, etc. The existing transaction logs are general system logs, which are system logs printed by developers during the development process according to application and alarm requirements.

[0003] However, there are some problems with the logs generated by existing technologies. For example, the logs generated by different R&D personnel are relatively personalized, which leads to a cumbersome identification process, low efficiency and high identification code cost in the subsequent log collection process. Summary of the invention

[0004] In view of this, the embodiments of the present invention provide a log generation method, apparatus and computer device to solve the problem that the logs generated in the related art are relatively personalized and difficult to identify in subsequent processes.

[0005] According to the first aspect, an embodiment of the present invention provides a log generation method, including: weaving a facet into a target service interface containing a point cut identifier in the business application; intercepting a business request sent by an upstream application based on the facet, and generating a request log for the business request in a first format; filtering downstream application response data related to the business request returned by a downstream application based on a filter, and generating a simulation log based on the filtering result; intercepting business response data for the business request based on the facet, and generating a response log in the first format based on the business response data.

[0006] Optionally, intercepting the business request sent by the upstream application based on the aspect and generating a request log for the business request in a first format include: parsing the target request, determining request parameters based on the parsing result, and constructing a request log object according to the request parameters; generating a request log in the standard log format according to the request log object.

[0007] Optionally, the filter-based method filters the downstream application response data related to the business request returned by the downstream application, and generates a simulation log based on the filtering result, including: determining the interface of the downstream application called by the filter, and when the downstream application interface meets the target conditions, determining the calling class name and the calling method name according to the called downstream application interface; when the calling class name and the calling method name are in a preset whitelist, generating the simulation log according to the downstream application response data.

[0008] Optionally, before the step of determining the downstream application interface called by the filter, the log generation method further includes: obtaining a log tracking number, the log tracking number is formed by creating a key value in a preset logger when the aspect intercepts the business request; and updating content information of a temporary state interceptor according to the log tracking number.

[0009] Optionally, the log generation method also includes: obtaining a set of application logs corresponding to the business request, the application logs including the request log, the response log and the simulation log; formatting the application logs, and generating target case objects corresponding to the request log, response log and simulation log based on the formatting results; and storing the target case objects corresponding to the request log, response log and simulation log in corresponding databases.

[0010] Optionally, the formatting the application log includes: formatting the application log to obtain a first formatted log; and cleaning the first formatted log to obtain a second formatted log.

[0011] Optionally, the formatting of the application log to obtain a first formatted log includes: when a target task identifier is extracted from the application log, generating a formatted information object according to the application log; storing the formatted information object in a corresponding target case in a preset data dictionary, the target case including the business request and its corresponding downstream application response data and business response data; when the target case is extracted from the preset data dictionary, generating the first formatted log.

[0012] Optionally, the cleaning the first formatted log to obtain the second formatted log includes: extracting the first formatted log of the same target case; when it is determined according to the first formatted log that the type of the target case is the required business type, adjusting the target case according to a preset rule; and generating the second formatted log according to the adjusted target case.

[0013] According to the second aspect, an embodiment of the present invention provides a log generation device, including: an aspect weaving module, used to weave aspects into a target service interface containing a point cut identifier in the business application; a request log generation module, used to intercept a business request sent by an upstream application based on the aspect, and generate a request log for the business request in a first format; a simulation log generation module, used to filter downstream application response data related to the business request returned by the downstream application based on a filter, and generate a simulation log based on the filtering result; a corresponding log generation module, used to intercept business response data for the business request based on the aspect, and generate a response log in the first format based on the business response data.

[0014] According to a third aspect, an embodiment of the present invention provides a computer device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the one processor, and the instructions are executed by the at least one processor so that the at least one processor performs the steps of the log generation method described in the first aspect or any one embodiment of the first aspect.

[0015] According to a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the log generation method described in the first aspect or any one of the embodiments of the first aspect are implemented.

[0016] The technical solution of the present invention has the following advantages:

[0017] The present invention provides a log generation method, device and computer equipment, wherein the log generation method includes: weaving a facet into a target service interface containing a pointcut identifier in a business application; intercepting a business request sent by an upstream application based on the facet, and generating a request log for the business request in a first format; filtering downstream application response data related to the business request returned by the downstream application based on a filter, and generating a simulation log based on the filtering result; intercepting business response data for the business request based on the facet, and generating a response log in a first format based on the business response data. By implementing the present invention, the problem that the generated logs in the related art are more personalized and the subsequent process is not easy to identify is solved, the interface log is screened in combination with a preset pointcut identifier, and without intruding the core code of the business, a request log and a response log in a unified format can be generated in combination with the preset facet, so that the generation of the log is decoupled from the business logic. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0019] Figure 1 A flowchart of a specific example of a log generation method in an embodiment of the present invention;

[0020] Figure 2 A flowchart of a specific example of a log generation method in an embodiment of the present invention;

[0021] Figure 3 is a principle block diagram of a specific example of a log generating device in an embodiment of the present invention;

[0022] Figure 4 FIG. 4 is a specific example diagram of a computer device in an embodiment of the present invention. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0024] At present, all projects in the online system support the printing of logs of application transaction data, that is, extracting data from transaction requests to generate transaction logs. However, the problem in the related technology is that the log format generated by the existing technology is relatively chaotic, and the interface method to which the log belongs is not displayed in the log, which is not conducive to the rapid analysis of the log generation case set. In other words, although the logs generated in the related technology are all system general logs, the logs generated by different R&D personnel have personal styles, which is not conducive to unified analysis.

[0025] Specifically, because the log format style is personalized, it is impossible to confirm the downstream interface or method to which the log content belongs based on the log, resulting in the inability of the automated testing tool to accurately match the simulated response when the transaction needs to call multiple downstream interfaces. In addition, to complete the automated testing of the entire application, it is necessary to generate logs for different transaction requests, responses to each downstream interface, and the final response. Currently, all of these are printed manually. When a new interface is added or changed, the log printing function must be added, which will cause a lot of redundancy and manpower investment.

[0026] The embodiments of the present invention provide a log generation method, an apparatus and a computer device, aiming to complete the generation of a general log without intruding into the core business code.

[0027] A complete transaction system may include upstream applications, intermediate applications, and downstream applications. The method provided in the embodiment of the present invention may be applied to intermediate applications. Specifically, the upstream application may be a bank or other payment institution, the intermediate application may be a payment clearing platform, and the downstream application may be a payment institution such as Alipay, etc. In other words, the method provided in the embodiment of the present invention may be used to receive a call request from an upstream application, and then call the intermediate application of the corresponding downstream application according to the call request from the upstream application. Specifically, the intermediate application may include a service interface, a preset aspect, a service, and a preset custom dubbo filter.

[0028] The embodiment of the present invention provides a log generation method, which can be executed by a terminal with a business application deployed, and the business application can be, for example, a payment application, a transaction application, etc. Figure 1 As shown, the log generation method includes:

[0029] Step S11: weaving a facet into the target service interface containing the pointcut identifier in the business application;

[0030] In this embodiment, the cut-point identifier can be a string, which is used to filter the target service interface of the intermediate application. Specifically, multiple service interfaces can be configured in the intermediate application. According to the actual application scenario requirements, the cut-point identifier can be set in the target service interface in advance. When the cut-point identifier is detected in the service interface, it is confirmed that this interface is the target service interface, that is, the interface that the user needs to monitor. At this time, the aspect is woven into the target service interface.

[0031] Step S12: intercepting the business request sent by the upstream application based on the aspect, and generating a request log for the business request in a first format;

[0032] In this embodiment, the upstream application sends a request to the service interface of the intermediate application. The upstream application can be a payment institution such as a bank, and the target request can be a transaction payment request, a data acquisition request, etc.; for example, when the bank (upstream application) sends a transaction payment request (target request) to the payment interface (target service interface) in the payment clearing platform, the aspect woven into the target service interface will intercept the target request.

[0033] In this embodiment, the first format may refer to a standard log format, which includes format information of an automated test identifier. For example, the standard log format may be: [automated test identifier: {"log tracking number":"","message number":"","log type":"","request initiation time":"","request parameters":""}].

[0034] In actual applications, for the same target request, the log tracking number saved in each log is the same, that is, according to the intercepted target request, a string of characters will be randomly determined as the tracking number of the generated log; the target request includes message number information and request initiation time information, and the actual type of the target request is determined according to the message number, and the actual type may include payment transaction request, refund request, and balance inquiry request, etc.; the request initiation time information is used to represent the time when the upstream application sends the request to the service interface of the intermediate application; the request parameter represents the information set sent by the upstream application to the service interface of the intermediate application; the log type is used to indicate the type of generated log, for example, it may include: the request log (request) received by the service interface of the intermediate application from the upstream application, and it may also include the response log (mock) received by the service interface of the intermediate application from the downstream application, and it may also include the response log (response) returned by the service interface of the intermediate application to the upstream application.

[0035] Specifically, a request log is generated according to the target request intercepted by the target service interface and the standard log format. The request log is a request log (request) received by the service interface of the intermediate application from the upstream application.

[0036] Step S13: filtering the downstream application response data related to the business request returned by the downstream application based on the filter, and generating a simulation log based on the filtering result.

[0037] In this embodiment, the business logic corresponding to the target request is determined according to the target request sent by the upstream application. Specifically, the business logic can be the logic of the business corresponding to the request during actual processing. The service in the intermediate application can determine the business processing logic according to the received target request, and then send the request to call the downstream application to the custom filter. Then, the custom filter can determine the corresponding downstream application interface according to the request to call the downstream application, and then the custom filter receives the downstream application response data returned by the downstream application.

[0038] For example, when the target request is a payment transaction request sent by an upstream application such as a bank, the payment interface in the payment clearing platform intercepts the payment transaction request according to the interwoven aspect, and generates a request log according to the standard log format. Then the payment interface in the payment clearing platform calls downstream applications such as Alipay according to the business processing logic. When downstream applications such as Alipay receive a call request from the service interface of the intermediate application, they perform business logic processing according to the request parameters in the call request. For example, they may generate a payment consent request, that is, return the "payment consent request" to the service interface of the intermediate application, that is, the service interface of the intermediate application receives the downstream application response data returned by the downstream application.

[0039] Then, in the custom filter, a simulation log is generated according to the downstream application response data. In the present embodiment, the custom filter may be, for example, a custom dubbo filter. When the custom dubbo filter in the intermediate application receives the downstream application response data returned by the downstream application, a simulation log (mock log) may be generated according to the downstream application response data and the standard log format. Specifically, the mock log may be generated only when it is determined that the downstream application interface corresponding to the downstream application response data is in the preset whitelist. The custom dubbo filter then returns the data of the corresponding target request that the downstream application has completed to the service layer in the intermediate application, that is, returns the business response data corresponding to the mock log to the service layer in the intermediate application.

[0040] Step S14: intercepting the business response data for the business request based on the aspect, and generating a response log in the first format based on the business response data. In this embodiment, the aspect woven into the intermediate application receives the business response data corresponding to the mock log returned by the service layer, continues to process the business logic, generates a response to the upstream application, that is, determines the business response data to the upstream application, constructs a log object according to the parameters in the business response data, and then generates a response log.

[0041] Specifically, when the custom dubbo filter of the intermediate application receives the downstream application response data returned by the downstream application, the business response data corresponding to the downstream application response data will pass through the service layer and re-enter the aspect. After intercepting the corresponding business request through the aspect, the subsequent business logic processing will continue, and finally generate the business response data for the upstream application. According to the business response data and the standard log format, a response log is generated, and then the business response corresponding to the business response data is returned to the upstream application. For example, for the above example, when the bank (upstream application) sends a transaction payment request (target request) to the payment interface (target service interface) in the payment clearing platform, the corresponding regretful business response can be to send "Alipay agrees to payment transaction request information" to the bank (upstream application). The response log is the response log (response) returned by the service interface of the intermediate application to the upstream application.

[0042] A log generation method provided by an embodiment of the present invention comprises: weaving a facet into a target service interface containing a cut-point identifier in a business application; intercepting a business request sent by an upstream application based on the facet, and generating a request log for the business request in a first format; filtering the downstream application response data related to the business request returned by the downstream application based on a filter, and generating a simulation log based on the filtering result; intercepting the business response data for the business request based on the facet, and generating a response log in a first format based on the business response data. By implementing the present invention, the problem that the generated logs in the related art are more personalized and the subsequent process is not easy to identify is solved, and the interface logs are screened in combination with a preset cut-point identifier. Under the premise of not invading the core code of the business, the preset facet and the custom filter can generate a request log, a simulation log and a response log in a unified format, and realize the decoupling of log generation and business logic, that is, by defining the preset facet, the decoupling of log generation and printing and business logic is realized, so that the service interface of the intermediate application, that is, the external interface of the intermediate application, can automatically generate and print logs according to the request and response data received by itself.

[0043] As an optional implementation of the present invention, the above step S12, intercepting the business request sent by the upstream application based on the aspect, and generating a request log for the business request in the first format, includes:

[0044] First, parse the target request, determine the request parameters based on the parsing result, and construct a request log object according to the request parameters; in this embodiment, when the target service interface of the intermediate application receives the target request, the preset aspect in the target service interface will intercept the above target request and then parse the target request; the request parameters may include message number information and request initiation time information; construct a request log object according to the request parameters and the initial object (a customizable object); it can also be when the target service interface of the intermediate application receives the target request, and it is determined that the target service interface is set with a tangent point identifier, at this time the preset aspect can be woven in in real time, and the preset aspect can then parse the target request and determine the request parameters.

[0045] Secondly, a request log is generated according to the request log object and the standard log format. In this embodiment, the standard log format may include: [Automation test identification: {"log tracking number": "", "message number": "", "log type": "", "request initiation time": "", "request parameters": ""}]. Then, a request log is generated according to the standard log format and the constructed request log object, that is, a request log (request) of the upstream application received by the intermediate application is generated.

[0046] A log generation method provided by an embodiment of the present invention intercepts a target request by weaving a preset aspect into the target service interface of an intermediate application, and then constructs a request log object according to the target request and an initial object to generate a request log. That is to say, without intruding into the original code, the external interface of the intermediate application can automatically generate and print logs according to the requests it receives, thereby increasing the scalability and versatility of the code.

[0047] As an optional implementation of the present invention, the above step S15, filtering the downstream application response data related to the business request returned by the downstream application based on the filter, and generating a simulation log based on the filtering result, includes:

[0048] First, according to the application request data, the downstream application interface called by the filter is determined, and when the downstream application interface meets the target condition, the calling class name and the calling method name are determined according to the interface of the calling downstream application;

[0049] In this embodiment, when the intermediate application calls the downstream interface, the service interface of the downstream application called by the custom filter (for example, the dubbo filter) is determined. When the interface of the downstream application meets the target conditions, it can be considered that the interface of the downstream application is a dubbo interface, that is, it meets the target conditions. Specifically, a custom dubbo interceptor is set in the intermediate application to intercept the call request of the target service interface that needs to call the dubbo interface of the downstream application. When the call request transmitted in the target service interface of the intermediate application needs to call the first dubbo interface of the downstream application, at this time, the business execution logic of the call request is executed, for example, the payment interface of the clearing platform can call the payment interface in the Alipay application based on the payment transaction request initiated by the received bank. At this time, the calling class name and the calling method name are determined according to the payment interface in the called Alipay application, for example, it can be a payment class and a payment method.

[0050] Secondly, when the calling class name and the calling method name are in the preset whitelist, the simulation log (mock log) is generated according to the downstream application response data.

[0051] In this embodiment, the preset whitelist can be a list of calling classes and a list of calling methods used by the interface determined according to the actual scenario application requirements / user requirements. That is to say, when the calling classes and calling methods in the preset whitelist are used, it is necessary to generate a mock log based on the response data generated after the call.

[0052] Specifically, all downstream call requests are intercepted in the middle-layer service, and the downstream interface information can be obtained based on the call, and then whitelist verification is performed. If it meets the whitelist information, a mock log will be generated. In other words, in the target service, the custom dubbo interceptor will intercept all requests to call the downstream dubbo interface.

[0053] A log generation method provided by an embodiment of the present invention combines a preset whitelist to screen whether a downstream interface generates a log, thereby reducing the generation of redundant logs, reducing energy consumption, and realizing automatic generation of logs.

[0054] As an optional embodiment of the present invention, before determining the interface of the downstream application called by the filter, the log generation method also includes: obtaining a log tracking number, wherein the log tracking number is formed by creating a key value in a preset logger when the aspect intercepts the business request; and updating the content information of the temporary status interceptor according to the log tracking number.

[0055] In this embodiment, when it is determined according to the target service interface of the intermediate application that the target request needs to call multiple interfaces of the downstream application, it is first determined whether the interfaces of the multiple downstream applications called all meet the target conditions, that is, it is determined whether the interfaces of the downstream applications called are all dubbo interfaces; when the interfaces of the downstream applications called are all dubbo interfaces, for example, the A interface may be called first, the B interface may be called secondly, and the C interface may be called last. At this time, before calling the A interface, the log tracking number is determined according to the call request generated by the target service interface, and then stored in the temporary status interceptor (RpcContext), and then the calling logic of the A interface is executed to determine the call class list and the call method list used when calling the A interface. When the call class and the call method belong to the preset whitelist, the response data returned by the A interface is received, and the A log (mock log) is generated according to the response data generated after the call.

[0056] Before executing the calling logic of interface B, first obtain the log tracking number through the temporary status interceptor, then update the content information of the temporary status interceptor according to the log tracking number, and then execute the calling logic of interface B to determine the list of calling classes and calling methods used when calling interface B. When the calling class and calling method belong to the preset whitelist, receive the response data returned by interface B, and generate B log (mock log) according to the content information in the updated temporary status interceptor and the returned response data.

[0057] Before executing the calling logic of the C interface, first obtain the log tracking number through the temporary status interceptor, then update the content information of the temporary status interceptor according to the log tracking number, and then execute the calling logic of the C interface to determine the calling class list and calling method list used when calling the C interface. When the calling class and calling method do not belong to the preset whitelist, only the response data returned by the C interface is received, and no mock log is generated at this time.

[0058] As an optional implementation of the present invention, the log generation method also includes: returning the business response corresponding to the business response data to the upstream application. In this embodiment, the custom dubbo filter in the intermediate application can receive the downstream application response data directly returned by the service interface in the downstream application, and then generate a business response, return the business response to the service layer in the intermediate application, and then the intermediate service layer returns the business response to the preset aspect after processing, and the preset aspect in the intermediate application returns the business response data corresponding to the received business response to the upstream application in the form of a business response.

[0059] For example, the target service interface of the intermediate application will receive the response data returned by the downstream application. After a series of processing by the service layer in the intermediate application, the service layer in the intermediate application will continue to generate it according to the business logic, and then generate a response to the upstream application, which is then returned to the upstream application. For example, the payment clearing platform returns the "agree to pay" information returned by Alipay to the bank.

[0060] The following is a specific example Figure 2 , describing in detail the execution process of the method described in the above embodiment, which is applied to the intermediate service interface 200. Specifically, the complete transaction system may include an upstream application 100, an intermediate service interface 200, a facet 300 woven into the intermediate service interface, and a downstream service interface 400.

[0061] Specifically, the upstream application 100 sends a request to the intermediate service interface 200. When the intermediate service interface 200 has a "cut-point" identifier, the aspect 300 can be woven into the intermediate service interface 200. The aspect 300 intercepts the request sent by the upstream application 100, obtains the request, builds a log object, and generates a log. Then the intermediate service interface 200 continues to execute the interface processing business logic and sends the call request to the downstream service interface 400. The downstream service interface 400 generates a business response based on the call request and returns it to the aspect 300 of the intermediate service interface 200. Then, a log object is built according to the response data in the business response to generate a log. Then, the aspect 300 of the intermediate service interface 200 returns the business response to the upstream application 100. When the intermediate service interface 200 calls the downstream interface 400, the request will be intercepted by the custom dubbo filter. When it meets the preset whitelist, a mock log will be generated. Then, after the intermediate service business processing, it is returned to the aspect 300 of the intermediate service interface 200.

[0062] That is to say, the custom dubbo filter will intercept all downstream interface calls. After interception, only the calls that meet the whitelist will print mock logs and return responses after the calls receive responses; those that do not meet the requirements will call the interface normally and return responses.

[0063] Compared with the existing transaction request, response, and downstream interface response log generation methods, the log generation method provided by the embodiment of the present invention is based on the principle of not intruding into the core business code, and uses aspects, filters, etc. to complete the log weaving in a unified format. By configuring the whitelist, the downstream responses that need to be recorded can be flexibly selected, which increases the scalability and versatility of the code. At the same time, it can be reused in other application systems. The complexity and difficulty of automated test case collection are reduced through a unified log style. By automatically printing the downstream interface name and method name, the downstream interface responses at different stages of the same transaction can be accurately distinguished, which is convenient for subsequent automated tests to return simulated responses.

[0064] Specifically, the method provided by the embodiment of the present invention decouples the full-process log printing function of the transaction in the service application from the application business logic code, and realizes the automatic printing of the log in a unified format at the same time, and connects the full-process log corresponding to the same request through the log tracking number in series, and finally confirms the return value of multiple downstream interfaces during the automated test by implanting the interface name and method name in the downstream log. By implementing the present invention, when adding an external interface or replacing and adding a downstream interface call in the application, there is no need to copy the repeated printing log code. At the same time, by setting a whitelist, dubbo filter (interceptor) can flexibly control which downstream interfaces are printed. The unified log format is more convenient for the automated test tool to parse the collection log, and there is no need to set complex rules. The case log required for the automated test is determined in the first time by whether the log contains an "automated test identifier". The whole scheme effectively reduces the development difficulty and system transformation risk, and can use the logs of real environments such as online to batch generate automated test cases, and has good versatility and can be reused in other transaction systems.

[0065] As an optional implementation of the present invention, the log generation method can also be applied to the field of automated testing. Specifically, automated testing can be to initiate a test request to the application to be tested according to the test case, simulate the downstream application, obtain the simulated response from the simulated response database according to the test request and return it to the application to be tested, the application to be tested processes it according to the simulated response, generates a request result and compares it with the standard response data corresponding to the target test case in the standard library; the automated test case is a case generated after special processing based on the log generated by the application to be tested in the production environment, obtaining the request parameters of the transaction access application; the MOCK case is also called a simulation case. Based on the log generated by the application to be tested in the production environment, the case is generated after the response data returned by the downstream service after the transaction access application is obtained and the downstream service is called, and the standard case is a case generated after processing based on the log generated by the application to be tested in the production environment, obtaining the response data generated after the transaction access application is obtained, and the standard case is a case generated after processing.

[0066] The log generation method also includes:

[0067] First, a set of application logs corresponding to the business request is obtained, and the application logs include one or more of request logs, response logs, and mock logs. In this embodiment, the application logs may be transaction logs / process logs obtained in an actual production environment, and may actually be request logs, mock logs, and response logs generated according to the above embodiments, and may include multiple types of the above logs, such as request logs, mock logs, and response logs, or request logs and response logs.

[0068] Then, the application log is formatted, and target case objects corresponding to the request log, response log and simulation log are generated respectively based on the formatting results;

[0069] The target case objects corresponding to the request log, response log and simulation log are respectively stored in the corresponding database.

[0070] As an optional implementation of the present invention, the process of formatting the application log mainly includes: first, formatting the application log to obtain a first formatted log; in this embodiment, reading multiple application logs generated in the production test environment, modifying the suffix of the read application log to (.log), and generating a log with the suffix .log. Formatting the log with the suffix .log to generate a log with the suffix (.formatted).

[0071] Secondly, the first formatted log is cleaned to obtain a second formatted log.

[0072] In this embodiment, the first formatted log is cleaned, that is, the first formatted log is screened according to a preset condition, and the suffix of the screened first formatted log is modified to (.cleaned), so as to generate a second formatted log.

[0073] Specifically, extract the first formatted log of the same target case; when it is determined that the type of the target case is the required business type according to the first formatted log, adjust the target case according to the preset rules; generate the second formatted log according to the adjusted target case. For example, a bank requests payment from a clearing platform, and the clearing platform calls Alipay to make payment according to the request. Alipay returns the "agree to pay" information to the clearing platform, and the clearing platform then returns the "agree to pay" information to the bank. The above process is a complete transaction case. Based on the filtered second formatted log, generate a target case object corresponding to the complete transaction case. Specifically, multiple case sets can be generated.

[0074] Secondly, according to the target case object, the request log is stored in the request log database, the response log is stored in the response log database, and the mock log is stored in the mock log database. In this embodiment, the request log is the request log, and the request log database is the case library; the response log is the response log, and the response log database is the standard library; the mock log is the mock log, and the mock log database is the MOCK library.

[0075] A log generation method provided by an embodiment of the present invention classifies the logs into a database according to the types of generated logs. By parsing the logs, real transaction cases can be obtained in batches, the test case library can be enriched, the application can be tested comprehensively, and the test coverage can be improved.

[0076] As an optional implementation manner of the present invention, in the above steps, formatting the application log to obtain a first formatted log includes:

[0077] First, when a preset identifier is extracted from the application log, a formatted information object is generated according to the application log; in this embodiment, the preset identifier may be an "automated test identifier". When the read application log contains the preset identifier, the formatted information object is assembled, that is, an initial formatted information object is generated.

[0078] Secondly, the formatted information object is stored in a preset data dictionary; in this embodiment, the preset data dictionary may be a map that caches multiple formatted objects. Specifically, all logs containing preset identifiers are formatted and stored in the preset data dictionary, that is, request logs, response logs, and mock logs are all stored in the preset data dictionary.

[0079] Secondly, when the target case is extracted from the preset data dictionary, a first formatted log is generated. In this embodiment, the target case can be a request log, a response log, and a mock log generated by the same transaction, that is, a series of logs corresponding to the same request are merged to generate a first formatted log corresponding to the target case set, and the log sets corresponding to different requests are separated by a separator "=======".

[0080] A log generation method provided by an embodiment of the present invention generates a first formatted log based on the formatting of an application log. All complete cases in the actual log that can be used for automated testing can be extracted and then processed in a unified manner. Requests, downstream responses, and response records of the same transaction scattered in different locations of the log are extracted and concentrated into a transaction case set, which is then written into a .formatted file. At the same time, delimiters are used to isolate different transaction sets, so that log sets corresponding to different transactions can be quickly distinguished.

[0081] As an optional implementation manner of the present invention, in the above steps, cleaning the first formatted log to obtain a second formatted log includes:

[0082] First, extract the first formatted log of the same target case; when it is determined that the type of the target case is the required business type according to the first formatted log, adjust the target case according to the preset rules; in this embodiment, the target case can be determined according to the actual application scenario requirements, or according to the actual needs of the user; the transaction corresponding to the first formatted log is required by the user, at this time, adjust the first formatted log according to the preset correction rules. When the transaction corresponding to the extracted first formatted log does not meet the user's needs, the first formatted log can be deleted.

[0083] Secondly, a second formatted log is generated according to the adjusted target case. In this embodiment, after the target transaction case is modified according to the preset modification rule, the initial (.cleaned) file is written to generate the second formatted log.

[0084] A log generation method provided by an embodiment of the present invention, combined with obtaining a case set of a transaction line by line from a .formatted file (including a request log, a response log, and a mock log), can quickly and accurately filter out the transaction types required by the user, and can also write the .cleaned file after correcting and adjusting the transaction cases according to special rules.

[0085] The following describes in detail a log generation method involved in an embodiment of the present invention in conjunction with a specific embodiment. Figure 2As shown, the log generation system may include upstream applications, intermediate applications and downstream applications. Specifically, the intermediate application includes a service interface, a facet, and a service (layer) based on a custom dubbo filter, and the downstream application includes a downstream service interface. Specifically, when the service interface in the intermediate application receives a request sent by the upstream application, it is determined that the service interface is set with a cut-point identifier. At this time, the service interface can intercept the transaction request, weave the facet into the intermediate application, and then parse the request with the facet, determine the request parameters, build a log object and generate a request log. After that, the service layer determines the business processing logic according to the request, and then determines the downstream application according to the business processing logic, and then uses the downstream service interface in the downstream application through the custom dubbo filter. After the downstream application processes it, the downstream application response data is returned to the custom dubbo filter in the intermediate application; custom dubbo filter According to the received downstream application response data, determine whether the downstream application interface corresponding to the downstream application response data is in the preset whitelist. If it is in the preset whitelist, generate a mock log, and then return it to the service (layer) in the form of a business response. The service (layer) returns it to the aspect in the form of a business response, that is, the business response data is returned to the aspect. The aspect determines the request parameters based on the received business response data, constructs a log object and generates a response log. The aspect then returns the business response data corresponding to the response log to the service interface. The service interface then returns the business response data to the upstream application in the form of a business response, completing the entire log generation process.

[0086] The embodiment of the present invention provides a log generation device, such as Figure 3 As shown, including:

[0087] The aspect weaving module 21 is used to weave aspects into the target service interface containing the pointcut identifier in the business application; the detailed implementation content can refer to the relevant description of step S11 in the above method embodiment.

[0088] The request log generation module 22 is used to intercept the business request sent by the upstream application based on the aspect, and generate a request log for the business request in the first format; the detailed implementation content can be found in the relevant description of step S12 in the above method embodiment.

[0089] The simulation log generation module 23 is used to filter the downstream application response data related to the business request returned by the downstream application based on the filter, and generate a simulation log based on the filtering result; the detailed implementation content can be found in the relevant description of step S13 in the above method embodiment.

[0090] The response log generation module 24 is used to intercept business response data for business requests based on aspects, and generate a response log in a first format based on the business response data; for detailed implementation content, please refer to the relevant description of step S14 in the above method embodiment.

[0091] A log generating device provided by the present invention includes: a section weaving module 21, which is used to weave sections into target service interfaces containing section point identifiers in business applications; a request log generating module 22, which is used to intercept business requests sent by upstream applications based on sections, and generate request logs for business requests in a first format; a simulation log generating module 23, which is used to filter downstream application response data related to business requests returned by downstream applications based on filters, and generate simulation logs based on filtering results; a response log generating module 24, which is used to intercept business response data for business requests based on sections, and generate response logs in a first format based on the business response data.

[0092] By implementing the present invention, the problem that the generated logs in the related art are more personalized and the subsequent processes are difficult to identify is solved. The interface logs can be screened in combination with the preset cut-point identifier. Without intruding the core code of the business, the request logs and response logs in a unified format can be generated in combination with the preset cut-point, thereby decoupling the log generation from the business logic.

[0093] The embodiment of the present invention also provides a computer device, such as Figure 4 As shown, the computer device may include a processor 31 and a memory 32, wherein the processor 31 and the memory 32 may be connected via a bus 30 or other means. Figure 4 The connection via bus 30 is taken as an example.

[0094] The processor 31 may be a central processing unit (CPU). The processor 31 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or a combination of the above chips.

[0095] The memory 32 is a non-transitory computer-readable storage medium that can be used to store non-transitory software programs, non-transitory computer executable programs and modules, such as program instructions / modules corresponding to the log generation method in the embodiment of the present invention. The processor 31 executes various functional applications and data processing of the processor by running the non-transitory software programs, instructions and modules stored in the memory 32, that is, implementing the log generation method in the above method embodiment.

[0096] The memory 32 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and applications required for at least one function; the data storage area may store data created by the processor 31, etc. In addition, the memory 32 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage devices. In some embodiments, the memory 32 may optionally include a memory remotely arranged relative to the processor 31, and these remote memories may be connected to the processor 31 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0097] The one or more modules are stored in the memory 32 and when executed by the processor 31, perform the following steps: Figure 1 The log generation method in the illustrated embodiment.

[0098] For details of the above computer equipment, please refer to Figure 1 The corresponding related descriptions and effects in the illustrated embodiments can be understood and will not be repeated here.

[0099] An embodiment of the present invention further provides a non-transitory computer-readable medium, which stores computer instructions. The computer instructions are used to enable a computer to execute a log generation method as described in any one of the above embodiments, wherein the storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), a flash memory (Flash Memory), a hard disk (Hard Disk Drive, abbreviated as: HDD) or a solid-state drive (SSD), etc.; the storage medium may also include a combination of the above-mentioned types of memories.

[0100] Obviously, the above embodiments are merely examples for the purpose of clear explanation, and are not intended to limit the implementation methods. For those skilled in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to list all the implementation methods here. The obvious changes or modifications derived therefrom are still within the scope of protection of the invention.

Claims

1. A log generation method, characterized in that: Executed by terminals with business applications deployed, including: Weaving a facet into a target service interface containing a pointcut identifier in the business application; Intercepting a business request sent by an upstream application based on the aspect, and generating a request log for the business request in a first format; Filtering downstream application response data related to the business request returned by the downstream application based on the filter, and generating a simulation log based on the filtering result; The business response data for the business request is intercepted based on the aspect, and a response log is generated in the first format based on the business response data.

2. The method according to claim 1, characterized in that The intercepting the business request sent by the upstream application based on the aspect, and generating a request log for the business request in a first format, includes: Parsing the target request, determining request parameters based on the parsing result, and constructing a request log object according to the request parameters; Generate a request log in a standard log format according to the request log object.

3. The method according to claim 1, characterized in that The filtering of downstream application response data related to the business request returned by the downstream application based on the filter, and generating a simulation log based on the filtering result, includes: Determine the interface of the downstream application called by the filter, and when the downstream application interface meets the target condition, determine the calling class name and the calling method name according to the called downstream application interface; When the calling class name and the calling method name are in the preset whitelist, the simulation log is generated according to the downstream application response data.

4. The method according to claim 3, characterized in that: Before the step of determining the interface of the downstream application called by the filter, the method further includes: Obtaining a log tracking number, where the log tracking number is formed by creating a key value in a preset logger when the slice intercepts the business request; The content information of the temporary status interceptor is updated according to the log tracking number.

5. The method according to claim 1, characterized in that Also includes: Obtaining a set of application logs corresponding to the business request, the application logs including one or more of the request log, the response log, and the simulation log; Formatting the application log, and generating target case objects corresponding to the request log, response log and simulation log respectively based on the formatting results; The target case objects corresponding to the request log, response log and simulation log are respectively stored in the corresponding database.

6. The method according to claim 5, characterized in that The formatting of the application log includes: Formatting the application log to obtain a first formatted log; The first formatted log is cleaned to obtain a second formatted log.

7. The method according to claim 6, characterized in that The step of formatting the application log to obtain a first formatted log includes: When a target task identifier is extracted from the application log, a formatted information object is generated according to the application log; The formatted information object is stored in a corresponding target case in a preset data dictionary, wherein the target case includes the business request and its corresponding downstream application response data and business response data; When the target case is extracted from the preset data dictionary, the first formatted log is generated.

8. The method according to claim 6, characterized in that The cleaning process of the first formatted log to obtain a second formatted log includes: extracting the first formatted log of the same target case; When it is determined according to the first formatted log that the type of the target case is the required business type, adjusting the target case according to a preset rule; The second formatted log is generated according to the adjusted target case.

9. A log generating device, characterized in that: include: Aspect weaving module, used for weaving aspects into target service interfaces containing pointcut identifiers in the business application; A request log generation module, configured to intercept a business request sent by an upstream application based on the aspect, and generate a request log for the business request in a first format; A simulation log generation module, used to filter downstream application response data related to the business request returned by the downstream application based on the filter, and generate a simulation log based on the filtering result; A response log generation module is used to intercept business response data for the business request based on the aspect, and generate a response log in the first format based on the business response data.

10. A computer device, characterized in that: include: at least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the one processor, and the instructions are executed by the at least one processor so that the at least one processor performs the steps of the log generation method described in any one of claims 1-8.

Images