Detailed Description
Embodiments of the present invention will be described below with reference to the accompanying drawings.
The log information recording method and device provided by the embodiment of the application are suitable for a scene that a server side records the execution result of the logic code of the service interface when responding to the call request of the service interface, and are particularly suitable for a scene that the execution results of a plurality of branch codes in the logic code of the service interface are recorded. The service interface is an entry provided by the server to the client for using the function of the client, that is, each service interface may correspond to a function, that is, the client may execute a service operation by calling the service interface of the server. The plurality of branch codes can be identified by preset numbers, wherein the preset numbers can be any information capable of representing the uniqueness of the branch codes. In one example, the preset number may be composed of letters and numbers and have a sequential nature. For example, the preset number may be: "-BK-1", "-BK-2", "-BK-3", etc.
It should be noted that the preset number may be set in each branch code by a developer when writing the logic code of the service interface. After the preset number is set for the branch code in the logic code of the service interface, when the service interface is called, that is, when the function corresponding to the service interface is executed, the relevant information in the process of responding to the call request can be output to the log file, where the relevant information may include the number of the branch code, the execution result, the interface parameter, and the like. The log file may be a log file corresponding to the service interface, that is, the log file may record relevant information in the process of responding to multiple call requests of the service interface, wherein the branch code executed in each call request may be identified by tracking the identification number.
Fig. 1 is a flowchart of a method for recording log information according to an embodiment of the present application, where an execution subject of the method may be a device with processing capability: as shown in fig. 1, the method may specifically include:
step 110, when the server receives a call request to the service interface, a tracking identification number corresponding to the call request is generated, and the tracking identification number is used for uniquely identifying the call request for one time.
The invocation request here may be sent by the client. Specifically, when receiving a call request to the service interface, the service end may start a corresponding thread, and the started thread sends the call request to the service interface, so as to complete execution of the logic code of the service interface.
In an example, the step 110 of generating the tracking identifier corresponding to the invocation request may specifically be:
acquiring an Internet Protocol (IP) address and current time information of the server;
and generating a tracking identification number corresponding to the calling request according to the IP address, the current time information and a preset threshold value.
For example, when the logic code of the service interface is written in the Java language, then the service interface can be implemented by the functions: gethostdress () to obtain the IP address of the server; the following processing may be performed on the IP address of the server: removing the point number in the IP address to obtain four numbers; for each of the four digits, it may be converted into corresponding hexadecimal data, where the conversion process for each digit may be: this number is assigned to the variable ipNum, after which finally by using the function: the integer, tohexstring (ipNum), then the corresponding two-bit hexadecimal data can be obtained; here, if the hexadecimal data obtained by any digital conversion is less than two bits, the hexadecimal data can be supplemented with a0 prefix. It will be appreciated that after each of the four digits is converted to corresponding hexadecimal data, eight bits of hexadecimal data are obtained. For example, assume that the acquired IP address of the server is: 1.1.1.1, after removing the dot number in the IP address, four digits are obtained: 1.1, 1 and 1; after converting the four numbers into corresponding hexadecimal data, it is still: 1.1, 1 and 1, because there are not enough two bits, the prefix 0 is supplemented, that is, the finally obtained hexadecimal data of eight bits is: 01010101.
further, by the function: system currenttimemillis () to obtain the number of milliseconds of the current time; in addition, because a server may receive multiple call requests simultaneously within one millisecond, in order to generate a different tracking identification number for each call request, the present application may also preset a threshold value, which may be an eight-bit self-increment sequence value, for example, the self-increment sequence value is 1 initially, when a next call request is received within the same millisecond, the self-increment sequence value becomes 2, and so on, until the self-increment sequence value reaches 9999999, the self-increment sequence value is accumulated again from 1, and the method can be used repeatedly. The tracking identification number can be generated by combining the IP address of the server, the number of milliseconds of the current time, and the incrementing sequence value. Since the call request of one server cannot exceed 9999999 in the same millisecond because the instruction request amount is estimated according to the traffic processing amount, the generation method of the tracking identification number can ensure the uniqueness. In one example, the generated tracking identification number may be: 0a0d87d 114544049250931001.
Of course, in practical applications, the tracking identification number may be generated by other methods as long as the uniqueness of the tracking identification number is ensured, and the present application does not limit the tracking identification number.
It will be appreciated that a call request by a service interface is responded to by one thread, and therefore the unique tracking identification number generated can be set into the context of the responding thread. Taking the logic code implemented by Java language as an example, when the trace identification number is denoted as traceId, the implementation code for setting the trace identification number to the context of the response thread may be: set (traceId).
And step 120, executing the logic code of the service interface, wherein the logic code comprises a plurality of branch codes, and each branch code is identified by a number.
In particular, logic code of the service interface, which may include multiple branch codes, may be executed upon receiving a call request sent by a responding thread. In one example, each branch code is determined by different values of interface parameters of the service interface. For example, the logic code of the service interface is as follows, where a is the interface parameter of the service interface.
…
If(a≤1){…};
Else if(1<a≤2){…};
Else{…};
…
In the above example, each line is a branch code in the logic code, that is, when the value of the interface parameter a is not greater than 1, the first branch code is executed; when the value of the interface parameter a is more than 1 and not more than 2, executing a second branch code; otherwise, when the value of the interface parameter a is larger than 2, executing a third branch code.
For purposes of this description, and by way of brevity, only one interface parameter and three branch codes for a service interface are listed in the example, and indeed, logical code may include tens of interface parameters for a service interface and may include hundreds of branch codes.
It should be further noted that the plurality of branch codes in the logic code may be identified by a preset number, where the preset number may be any information that can represent the uniqueness of the logic code. In one example, the preset number may be composed of letters and numbers and have a sequential nature. For example, the preset number may be: "-BK-1", "-BK-2", "-BK-3", etc.
The preset number can be set in each branch code when a developer writes a logic code of the service interface; in addition, the developer may also set a tracking identification number in the logic code of the service interface. Referring to the schematic diagram of the logic code shown in fig. 2, "-BK-1", "-BK-2", "-BK-3", …, "-BK-7" in fig. 2 are numbers of branch codes preset in the logic code by the developer; furthermore, the trace identification number generated in the process of responding to the current call request can be obtained in real time through the function thread local.
Step 130, if a first branch code of the plurality of branch codes is executed, outputting a corresponding relationship among the tracking identification number, the number of the first branch code, and the execution result to a log file.
The log file may be a log file corresponding to the service interface, that is, the log file may record relevant information in the process of responding to multiple call requests of the service interface, wherein the branch code executed in each call request may be identified by tracking the identification number. Further, the first branch code may be any one of a plurality of branch codes.
It can be understood that, although the logic code of the service interface includes a plurality of branch codes, only a part of the branch codes may be executed in the process of responding to a call request of the service interface, that is, in the process of executing a business operation, and therefore, only the branch codes executed in the process of responding to a call request need to be recorded in the log file.
In an example, the log information recorded in the log file may be as shown in fig. 3, and as can be seen from fig. 3, the tracking identification number corresponding to the current invocation request is: 0a0d87d114544049250931001, and the numbers of the branch codes executed in the process of responding to the current call request are: P-B-1, P-B-3, P-B-6, P-B-14, P-B-15 and P-B-18. In addition, the log information in fig. 3 may further include entry parameters of the service interface and an execution result of each branch code. Therefore, it can be seen that, while recording the entry parameters and execution results of the branch codes, the log file of the present application also records the tracking identification number generated in the process of responding to the current call request and the number of the executed branch code, so that developers can conveniently track the problems by analyzing the branch codes and the execution results thereof corresponding to the number recorded in the log file when determining that the request result of the current call request is not in accordance with the expectation.
It should be noted that, in the log file shown in fig. 3, for each branch code, a corresponding tracking identification number is recorded, so that according to the tracking identification number, a branch code executed in the process of responding to the call request identified by the tracking identification number can be read; that is, the log file shown in fig. 3 records branch matching summary information.
It can be understood that, because the server (service cluster) can respond to multiple call requests of the same service interface simultaneously, the log file shown in fig. 3 may further include other trace identification numbers, numbers of branch codes executed in the process of responding to call requests corresponding to other trace identification numbers, and corresponding relations of execution results; the recording method of the branch matching summary information is similar to the recording method in fig. 3, and is not repeated herein. It is understood that the branch matching summary information of multiple call requests is arranged at intervals, that is, the branch matching information in the process of responding to one call request is recorded in discontinuous rows. In particular, see the following examples:
tracking identification number 1 branch 1 execution result 1;
tracking identification number 2 branch 1 execution result 2;
tracking identification number 1 branch 3 execution result 3;
…
after the logic code of the service interface is executed, that is, after one service operation is executed, the service end can return the execution result of the service operation to the client; the execution result may be a correct result returned when the business operation is executed correctly, or may be an error result returned when the business operation fails to be executed.
It should be noted that after the execution result is returned to the client, the trace identification number corresponding to the call request of this time may also be output to another log file, as shown in fig. 4, where the another log file may be used to record summary information when responding to the call request of this time, such as a name of a service interface, parameter information, and the trace identification number. Of course, in practical applications, the summary information may be directly output to the log file shown in fig. 3, which is not limited in the present application.
It is understood that, at the beginning of a call request of the service interface, the generated tracking identification number is set into the context of the response thread; when the call request is finished, the context of the thread needs to be cleaned up, for example, the tracking identification number is removed, so that the thread can be reused.
After the log files shown in fig. 3 and 4 of the present application are generated, when the request result of one call request of the service interface is an error result, that is, when the request result is not in expectation, the present application may further provide the method for reading the log file shown in fig. 5 to read the branch codes executed in the process of responding to the call request, so that the problem when responding to the call request is tracked by analyzing the branch codes and the execution result thereof; as shown in fig. 5, the embodiment of the present application includes the following steps:
step 510, receiving a query instruction input by a user, where the query instruction includes a tracking identification number and a name of a log file.
Here, the tracking identification number may be read from the log file shown in fig. 4 according to the name of the service interface, the name of the log file, and the interface parameter, where the name of the service interface, the name of the log file, and the interface parameter may all be known in advance, and for example, may be read through the following command line:
grep CustomerSearchFacade/opt/logs/rpc-server-digest log | grep Zhang three | grep 33010;
wherein "customer SearchFacade" is the name of the service interface, "rpc-server-digest. log" is the name of the log file shown in FIG. 4, "Zhang three" and "33010" etc. are the interface parameters; the tracking identification number read from the log file shown in fig. 4 by the above command may be: 0a0d87d 114544049250931001.
Step 520, obtaining the corresponding log file according to the name of the log file.
Step 530, according to the tracking identification number, reading the numbers of the plurality of branch codes corresponding to the tracking identification number and the execution result from the log file.
After reading the tracking identification number, the numbers of the branch codes executed in the process of responding to the current call request can be read from the log file shown in fig. 3 according to the tracking identification number and the name of the log file. For example, it can be read by the following command line:
$grep 0a0d87d114544049250931001search-digest.7dt.log
wherein "search-digest.7dt.log" is the name of the log file shown in fig. 3; namely, firstly, obtaining the log file shown in FIG. 3 according to "search-digest.7dt.log"; thereafter, the number of the branch code corresponding to "0 a0d87d 114544049250931001" is read from the log file: P-B-1, P-B-3, P-B-6, P-B-14, P-B-15 and P-B-18, and the execution results, and also the interface parameters of each branch code may be read. It is understood that, because the log file shown in fig. 3 only records the number of each branch code executed in the process of responding to one call request, the result read in this step is the content shown in fig. 3.
Developers can quickly track the problems by analyzing the branch codes executed in the process of responding to the calling request and the execution result of the branch codes, so that the reasons of the problems can be quickly positioned, the problem that the client requests cannot have correct results is solved, and the expansion of the influence is avoided.
In summary, because the log file of the present application records the tracking identification number corresponding to the call request, and records the number of the branch code executed in the process of responding to the call request at one time; therefore, when the request result of one call request is not in expectation, the branch code executed in the process of responding to the current call request can be quickly determined according to the number of the branch code recorded in the log file, and the problem can be quickly positioned by analyzing the execution result of the executed branch code.
Corresponding to the above method for recording log information, an embodiment of the present application further provides a device for recording log information, as shown in fig. 6, the device includes: a generation unit 601, an execution unit 602, and an output unit 603.
The generating unit 601 is configured to generate a tracking identification number corresponding to a call request when a service end receives the call request for a service interface, where the tracking identification number is used to uniquely identify a primary call request.
Wherein, the generating unit 601 is specifically configured to:
acquiring an Internet Protocol (IP) address and current time information of the server;
and generating a tracking identification number corresponding to the calling request according to the IP address, the current time information and a preset threshold value.
An execution unit 602, configured to execute the logic code of the service interface, where the logic code includes multiple branch codes, and each branch code is identified by a number.
Wherein the plurality of branch codes may be determined by different values of interface parameters of the service interface.
An output unit 603, configured to output, if a first branch code of the plurality of branch codes is executed, a corresponding relationship between the tracking identification number, the number of the first branch code, and the execution result to a log file.
Optionally, the apparatus further comprises: a receiving unit 604 and a reading unit 605.
A receiving unit 604, configured to receive an inquiry instruction input by a user, where the inquiry instruction includes the tracking identification number and the name of the log file.
A reading unit 605, configured to obtain the log file according to the name of the log file, and read the numbers of the executed branch codes corresponding to the tracking identification number and the execution result from the log file.
Optionally, the output unit 603 is further configured to output the name of the service interface, the parameter information, and the tracking identification number to another log file.
The functions of the functional modules of the device in the embodiment of the present application may be implemented through the steps in the method embodiment described above, and therefore, the specific working process of the device provided in the present application is not repeated herein.
According to the log information recording device, when a server receives a call request for a service interface, a generating unit 601 generates a tracking identification number corresponding to the call request; the execution unit 602 executes the logic code of the service interface, where the logic code includes a plurality of branch codes, and each branch code is identified by a number; if a first branch code of the plurality of branch codes is executed, the output unit 603 outputs the corresponding relationship among the trace identification number, the number of the first branch code, and the execution result to a log file. Therefore, the log information of the one-time calling request of the service interface can be effectively recorded, and the problem of the logic code of the service interface can be effectively tracked.
Those of skill would further appreciate that the various illustrative objects and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied in hardware, a software module executed by a processor, or a combination of the two. A software module may reside in Random Access Memory (RAM), memory, Read Only Memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
The above-mentioned embodiments, objects, technical solutions and advantages of the present application are described in further detail, it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present application, and are not intended to limit the scope of the present application, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present application should be included in the scope of the present application.