CN117235026A - Log processing method and related device - Google Patents

Abstract

The embodiment of the application discloses a log processing method and a related device, which can solve the problem of repeated recording of a large amount of redundant information, and under the condition of changing log information, the log processing method and the related device do not need to be modified in each log embedded point, so that the recording logic of the whole log file is clearer, and the subsequent maintenance of the log file is facilitated. The method comprises the following steps: acquiring a service request, wherein the service request comprises context information when the service request is currently executed; acquiring target parameters from the context information, wherein the target parameters are used for indicating the object condition of a target object when executing the service request and/or the service related condition of the service request; and adding the target parameters into the log header, and adding the log header added with the target parameters into the log main body to obtain the target log file.

Description

Log processing method and related device

Technical Field

The embodiment of the application relates to the technical field of computers, in particular to a log processing method and a related device.

Background

The internet service and applications, various electronic devices, etc. generate logs at run-time. The log is mainly used for recording the time and the event when the program runs to a certain position and the custom log content at the service side, can record the event when the key service runs, and lays a foundation for the follow-up troubleshooting or the understanding of the service running state.

In the related scheme, if the complete log content needs to be printed in the process of executing the service request, the needed object manually splices the needed log information into the log content. For example, in a business scenario such as a coroutine scenario, when an input/output request or a network request is executed, there is a possibility that the currently executed business logic is switched to another logic flow, and if the complete object information is printed only at the start position of the execution of the remote procedure call (remote procedure call, RPC), it is highly possible that when the logic flow is switched back, the contents such as the current object information cannot be viewed from the log content, that is, it cannot be seen which object the executed logic flow is for. In this case, it is necessary to manually splice the contents such as the object information at each execution request into the log contents, and then complete the printing of the log contents.

However, the current processing method needs to splice all information to the log content each time a request is executed, and thus a large amount of redundant information is easily repeatedly recorded. If other log information needs to be added, modification is needed on each log embedded point, so that the redundant information of the whole printed log file is more, and the subsequent maintenance of the log file is not facilitated.

Disclosure of Invention

The embodiment of the application provides a log processing method and a related device, which can solve the problem of repeated recording of a large amount of redundant information, and under the condition of changing log information, the log processing method and the related device do not need to be modified in each log embedded point, so that the recording logic of the whole log file is clearer, and the subsequent maintenance of the log file is facilitated.

In a first aspect, an embodiment of the present application provides a method for log processing. The method comprises the following steps: acquiring a service request, wherein the service request comprises context information when the service request is currently executed; acquiring target parameters from the context information, wherein the target parameters are used for indicating the object condition of a target object when executing the service request and/or the service related condition of the service request; and adding the target parameters into the log header, and adding the log header added with the target parameters into the log main body to obtain the target log file.

In a second aspect, an embodiment of the present application provides a log processing apparatus. The log processing device comprises an acquisition unit and a processing unit. The acquiring unit is configured to acquire a service request, where the service request includes context information when the service request is currently executed. And the processing unit is used for acquiring target parameters from the context information, wherein the target parameters are used for indicating the object condition of a target object when the service is requested and/or the service related condition when the service is requested. The processing unit is used for adding the target parameters into the log header, and adding the log header added with the target parameters into the target main body to obtain the target log file.

In some possible implementations, the processing unit is further configured to: the target print function is invoked based on the context information to respond to the target print function for printing the target log file.

In some possible implementations, the processing unit is further configured to: acquiring a log identifier from the target log file, wherein the log identifier is used for indicating whether the target log file is subjected to dyeing treatment or not; and calling a corresponding target printing function according to the context information based on the log identification.

In other possible implementations, the target print function includes a dye log print function. The processing unit is used for: when the log mark indicates that the target log file is subjected to dyeing treatment, determining that the target log file is a dyeing log; and when the target log file is a dyeing log, calling a dyeing log printing function based on the context information.

In other possible implementations, the processing unit is configured to: when the log mark indicates that the target log file is not dyed, determining that the target log file is a non-dyed log; and when the target log file is a non-staining log, calling a general log printing function based on the context information.

In other possible implementations, the processing unit is configured to splice the log header of the target parameter before the log body, to obtain the target log file.

In other possible implementations, the processing unit is further configured to delete the context information after being used to print the target log file based on the target print function.

A third aspect of an embodiment of the present application provides a log processing apparatus, including: memory, input/output (I/O) interfaces, and memory. The memory is used for storing program instructions. The processor is configured to execute program instructions in the memory to perform a method of log processing corresponding to the implementation manner of the first aspect.

A fourth aspect of the embodiments of the present application provides a computer-readable storage medium having instructions stored therein, which when run on a computer, cause the computer to perform to execute the method corresponding to the embodiment of the first aspect described above.

A fifth aspect of the embodiments of the present application provides a computer program product comprising instructions which, when run on a computer or processor, cause the computer or processor to perform the method described above to perform the embodiment of the first aspect described above.

From the above technical solutions, the embodiment of the present application has the following advantages:

in the embodiment of the application, the service request is acquired, the service request comprises the context information when the service request is currently executed, and further, the target parameter is acquired from the context information and is used for indicating the object request of the target object and/or the service related condition of the service request when the service request is executed. Thus, the target parameters can be added to the log header, and the log header to which the target parameters are added is added to the log body, so that the target log file is obtained. In other words, in the embodiment of the application, the log file can be obtained by only adding the target parameters under different service scenes to the log header and splicing the log header to the log main body, so that all information is not required to be spliced to the log main body when service requests are executed each time, the problem of repeated recording of redundant information is solved, and in the case of changing the log information, the record logic of the whole log file is clearer and the subsequent maintenance of the log file is facilitated because the record logic of each log embedded point is not required to be modified.

Drawings

In order to more clearly illustrate the embodiments of the application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 shows a code schematic diagram of log information splicing in a prior art scheme;

FIG. 2 is a schematic diagram of a log processing framework provided by an embodiment of the present application;

FIG. 3 is a flow chart of a method of log processing provided by an embodiment of the present application;

FIG. 4 is a pseudo code schematic diagram of a context management module according to an embodiment of the present application when processing a service request;

FIG. 5 is a pseudo code schematic diagram of a log output module according to an embodiment of the present application when a log header is set;

FIG. 6 illustrates a pseudo code schematic of a log file record provided in an embodiment of the present application;

FIG. 7 is a schematic diagram illustrating the output of a target log file according to an embodiment of the present application;

FIG. 8 is a schematic diagram showing the structure of a log processing apparatus according to an embodiment of the present application;

fig. 9 shows a schematic hardware structure of a log processing device provided in an embodiment of the present application.

Detailed Description

The embodiment of the application provides a log processing method and a related device, which can solve the problem of repeated recording of a large amount of redundant information, and under the condition of changing log information, the log processing method and the related device do not need to be modified in each log embedded point, so that the recording logic of the whole log file is clearer, and the subsequent maintenance of the log file is facilitated.

It will be appreciated that in the specific embodiments of the present application, related data such as user information is involved, and when the above embodiments of the present application are applied to specific products or technologies, user permissions or consents need to be obtained, and the collection, use and processing of related data need to comply with related laws and regulations and standards of related countries and regions.

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

The terms "first," "second," "third," "fourth" and the like in the description and in the claims and in the above drawings, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the application described herein may be capable of being practiced otherwise than as specifically illustrated and described. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

In the related scheme, in the process of executing the service request, the required log information needs to be spliced into the log content manually, so that the printing of the complete log content can be performed. Taking the service request of modifying the user name as an example, fig. 1 shows a code schematic diagram of log information splicing in the existing scheme. As shown in fig. 1, each time a service request for modifying a user name is executed, it is possible to cause currently executed service logic to be switched into other logic flows, for example: the currently executed service logic log_debug ("change user name, seq:% s, user_id:% s, new_name"% s ", current_rpc.seq, current_user_id, new_name) is switched to the service logic log_debug (" query same user name, seq:% s, user_id:% s, new_name "% s", current_rpc.seq, current_user_id, new_name) and the like. However, if the complete object information is printed only at the start position of the RPC execution, when the logic flow is switched back, the current content (for example, current_user_id, new_name, etc.) such as the object information cannot be seen from the log content, that is, it is impossible to see which object the logic flow is executed for. At this time, it is necessary to manually splice object information such as an object ID, an object name, etc. of the current object into the log content each time the request is executed, and then complete printing of the log content.

However, the current processing method needs to splice all information to the log content each time a request is executed, and thus a large amount of redundant information is easily repeatedly recorded. For example, object information such as current_rpc.seq, current_user.user_id, new_name, and the like shown in fig. 1 is repeatedly recorded. In addition, if other log information needs to be updated, modification is needed on each log embedded point, so that the redundant information of the whole printed log file is more, and the subsequent maintenance of the log file is not facilitated.

Based on this, in order to solve the technical problems described above, the embodiment of the present application provides a log processing method. The method can be applied to devices such as a server and terminal equipment, and the application is not limited to the specific description. In a schematic way, taking an example of application of the log processing method in a server as an illustration, fig. 2 shows a schematic diagram of a log processing framework provided by an embodiment of the present application. As shown in fig. 2, the server may include a context management module and a log output module. The context management module is mainly used for acquiring a service request, adding context information when the service request is currently executed in an execution flow fixed in service logic of the service request, and further acquiring a target parameter from the context information. It is to be understood that the described context information may be understood as an environmental parameter when executing the service request. The business logic in the context management module is generally the outermost abstract logic of all business processes in the business request, i.e. each business process is pulled and executed by the context management module.

The described log output module is mainly used for adding the corresponding target parameters to the log header, and further adding the log header to the original log body, so that the corresponding target log file is obtained. The log output module may be used to identify each service scenario, and then splice different parameter values into the original log body according to different service scenarios.

It should be noted that, the foregoing main fig. 2 mainly uses an execution body as a server as an example, and other types of execution bodies are possible in practical applications, which is not specifically limited to the present application. In addition, the described server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, a cloud server for providing a cloud computing service, or the like, and the present application is not limited in particular. In addition, the service request for modifying the user name shown in fig. 1 is also merely a schematic description, and other service requests may be used in practical applications, which is not specifically limited by the present application.

The following describes a log processing method according to an embodiment of the present application with reference to the accompanying drawings. Fig. 3 shows a flowchart of a method for log processing according to an embodiment of the present application. As shown in fig. 3, the log processing method may include the steps of:

301. and acquiring a service request, wherein the service request comprises context information when the service request is currently executed.

In this example, the context information may be understood as environmental information when the service request is currently performed. For different service requests, the corresponding context information may also be different when executing different service requests. For example, the context information may be an execution time-consuming supervision record of the current rpc process execution, a callback function that needs to be focused on, a global parameter related to the service, and the like, which is not specifically limited by the present application. In addition, the service request may be a service request for modifying a user name as shown in fig. 1, a service request for an object to acquire a friend circle dynamic state, or a team service request in a virtual game, etc., which is not particularly limited in the present application.

302. And acquiring target parameters from the context information, wherein the target parameters are used for indicating the object condition of a target object when executing the service request and/or the service related condition of the service request.

In this example, the target parameter may be understood as information that requires significant attention when executing the service request, e.g., the target parameter may indicate one or more of an object condition of a target object when executing the service request, and a service related condition of the service request. The target parameters that need to be focused on may be different for different traffic scenarios. For example, in response to a service request event from an object, for example, when the object clicks a button of a software or an application, or when the object requests to access a web page, the object condition such as an Identity (ID) of the object, a user name, etc. when the service request is generated, and the service-side customized service-related condition such as an ID of the RPC, etc. need to be printed in a log file. In response to a service request event from another service, it is also necessary to print out the service-related conditions such as the ID of the server or RPC from which the service request is received in the log file.

It should be noted that, the service related situation may include, but is not limited to, in-process resource usage situations, such as a central processing unit (central processing unit, CPU), a memory, etc., besides the ID of the RPC, and the present application is not limited to this. In addition, the object case of the described target object may include, but is not limited to, location information of the object, etc., in addition to the object ID and the user name, and the present application is not particularly limited to the description.

Illustratively, taking the server shown in fig. 2 as an execution subject, the service request may be obtained through a context management module in the server. For example, fig. 4 shows a pseudo code schematic diagram when a context management module provided by an embodiment of the present application processes a service request. As shown in fig. 4, a process in the context management module first goes into "process_task (seq) before any traffic is processed: ctx=set_ctx (req) function, where req represents a task parameter currently required to be processed, and ctx is a global data structure for describing a service environment and various parameters of a current process. When the service request is executed by the current process, the context management module can set the context information of the current process according to the service environment where the current process is located and various parameters, so that the service request comprises the context information, the environment where the process executes the service request can be identified by using the global variable, and various target parameters needing to be concerned can be conveniently acquired during subsequent processing tasks. In some possible examples, the context management module may also execute specific business logic, that is, the context information is transmitted to the log output module, and the log output module performs operations such as splicing of target parameters and printing of log files.

303. And adding the target parameters into the log header, and adding the log header added with the target parameters into the log main body to obtain the target log file.

In this example, after the target parameter is obtained from the context information, the target parameter may be added to the log header without adding the target parameter to each business logic. Thus, after the log header to which the target parameter is added is obtained, the log header can be added to the log body, thereby obtaining the target log file. The target log file may be obtained by concatenating the log header to which the target parameter is added before the log body, for example.

304. The target print function is invoked based on the context information to respond to the target print function for printing the target log file.

In this example, after the target log file is obtained, the target log file output may also be printed. For example, it may be determined which log print module the current target log file adopts, i.e., which target print function is called, based on the context information, so that the called target print function is responded to, and the print input to the target log file is implemented using the target print function.

For example, different types of log print functions may be invoked for different types of log files. For example, a log identifier indicating whether the target log file is subjected to the dyeing process may be obtained from the target log file, and then a corresponding target print function is called according to the context information based on the log identifier. For example, when the log identifier indicates that the target log file has been subjected to the dyeing process, it may be determined that the target log file is a dyeing log, and then, when the target log file is a dyeing log, a dyeing log printing function is called based on the context information. The described staining log can be understood as marking a log file generated by a specific object as a staining state, and the log file of a specified level generated by the action of the object can be printed out later, so that the problem can be conveniently checked in certain generating environments. For example, since the debug log is not opened in the production environment generally, but an abnormal business condition of an object needs to be checked in some business scenarios, a debug-level log file generated by the object needs to be dyed, so that subsequent abnormal condition checking is facilitated.

Similarly, when the log mark indicates that the target log file is not dyed, the target log file can be determined to be a non-dyed log, and then when the target log file is the non-dyed log, a general log printing function is called based on the context information, and further printing and outputting of the log file of the non-dyed log is realized based on the general log printing function.

The context information may also be deleted, for example, after the target log file is printed based on the target print function. For example, as can be seen from fig. 4, after the context management module executes the service logic, the context management module can also clear the current context information through the code "clear_ctx ()", so that the phenomenon that the service logic executes errors caused by confusion of the environment information when the next task is processed can be avoided.

Illustratively, taking the server shown in fig. 2 as an execution body, the target parameters may be added to the log header by the log output module in the server and spliced into the log body. For example, fig. 5 shows a pseudo code schematic diagram when the log output module sets the log header according to the embodiment of the present application. As shown in fig. 5, the log output module may set target parameters, such as a user.id, a user.name, a team.id, etc., in the log header under different service request scenarios, and then splice the log header before the log body content, to obtain the log file content'. Then, when the log file content ' is printed, a corresponding log printing function may be called based on the context information, for example, when the log file content ' is a dye log, a do_print_feature_log (content ') function may be called for printing; alternatively, when the log file content 'is a non-stained log, a do_print_common_log (content') function may be called for printing. It should be noted that the content of the service request, the print function, etc. shown in fig. 5 is only a schematic description, and other requests and print functions may be used in practical applications, which is not specifically limited by the present application.

In the embodiment of the application, since the service request includes the context information when the service request is currently executed, the target parameter can be obtained from the context information by obtaining the service request, where the target parameter is used to indicate the object request of the target object and/or the service related condition of the service request when the service request is executed. Thus, the target parameters can be added to the log header, and the log header to which the target parameters are added is added to the log body, so that the target log file is obtained. In other words, in the embodiment of the application, the log file can be obtained by only adding the target parameters under different service scenes to the log header and splicing the log header to the log main body, so that all information is not required to be spliced to the log main body when service requests are executed each time, the problem of repeated recording of redundant information is solved, and in the case of changing the log information, the record logic of the whole log file is clearer and the subsequent maintenance of the log file is facilitated because the record logic of each log embedded point is not required to be modified. For example, fig. 6 shows a pseudo code schematic of a log file record provided in an embodiment of the present application. As shown in fig. 6, taking the service scenario shown in fig. 1 as an example, after the method for processing the log provided by the present application is applied, the target parameters need to be added in the log header, and the corresponding log header needs to be added before the log main body, so that the target parameters do not need to be added in each log embedded point. In addition, with respect to the output manner of the target log file shown in fig. 6, it may also be understood with reference to the output schematic diagram of the target log file shown in fig. 7, which is not described herein.

The foregoing description of the solution provided by the embodiments of the present application has been mainly presented in terms of a method. It should be understood that, in order to implement the above-described functions, hardware structures and/or software modules corresponding to the respective functions are included. Those of skill in the art will readily appreciate that the various illustrative modules and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. 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 embodiment of the application can divide the functional modules of the device according to the method example, for example, each functional module can be divided corresponding to each function, and two or more functions can be integrated in one processing module. The integrated modules may be implemented in hardware or in software functional modules. It should be noted that, in the embodiment of the present application, the division of the modules is schematic, which is merely a logic function division, and other division manners may be implemented in actual implementation.

The following describes the log processing device in the embodiment of the present application in detail, and fig. 8 is a schematic diagram of an embodiment of the log processing device provided in the embodiment of the present application. As shown in fig. 8, the log processing apparatus may include an acquisition unit 801 and a processing unit 802. The acquiring unit 801 is configured to acquire a service request, where the service request includes context information when the service request is currently executed. The processing unit 802 is configured to obtain, from the context information, a target parameter, where the target parameter is used to indicate an object condition of a target object at the time of service request and/or a service related condition at the time of service request. The processing unit 802 is configured to add the target parameter to the log header, and add the log header to which the target parameter is added to the target body, so as to obtain the target log file.

In some possible implementations, the processing unit 802 is further configured to: the target print function is invoked based on the context information to respond to the target print function for printing the target log file.

In other possible implementations, the processing unit 802 is further configured to: acquiring a log identifier from the target log file, wherein the log identifier is used for indicating whether the target log file is subjected to dyeing treatment or not; and calling a corresponding target printing function according to the context information based on the log identification.

In other possible implementations, the target print function includes a dye log print function. The processing unit 802 is configured to: when the log mark indicates that the target log file is subjected to dyeing treatment, determining that the target log file is a dyeing log; and when the target log file is a dyeing log, calling a dyeing log printing function based on the context information.

In other possible implementations, the processing unit 802 is configured to: when the log mark indicates that the target log file is not dyed, determining that the target log file is a non-dyed log; and when the target log file is a non-staining log, calling a general log printing function based on the context information.

In other possible implementations, the processing unit 802 is configured to concatenate the log header of the target parameter before the log body to obtain the target log file.

In other possible implementations, the processing unit 802 is further configured to delete the context information after being used to print the target log file based on the target print function.

The log processing apparatus in the embodiment of the present application is described above from the point of view of the modularized functional entity, and the log processing apparatus in the embodiment of the present application is described below from the point of view of hardware processing. Fig. 9 is a schematic structural diagram of a log processing device according to an embodiment of the present application. The log processing device can generate relatively large differences due to different configurations or performances. The log processing means may comprise at least one processor 901, communication lines 907, memory 903 and at least one communication interface 904.

The processor 901 may be a general purpose central processing unit (central processing unit, CPU), microprocessor, application-specific integrated circuit (server IC), or one or more integrated circuits for controlling the execution of programs in accordance with aspects of the present application.

Communication line 907 may include a pathway to transfer information between the aforementioned components.

The communication interface 904, uses any transceiver-like device for communicating with other devices or communication networks, such as ethernet, radio access network (radio access network, RAN), wireless local area network (wireless local area networks, WLAN), etc.

The memory 903 may be a read-only memory (ROM) or other type of static storage device that may store static information and instructions, a random access memory (random access memory, RAM) or other type of dynamic storage device that may store information and instructions, and the memory may be stand-alone and coupled to the processor via a communication line 907. The memory may also be integrated with the processor.

The memory 903 is used for storing computer-executable instructions for executing the present application, and is controlled by the processor 901. The processor 901 is configured to execute computer-executable instructions stored in the memory 903, thereby implementing the log processing method provided in the above embodiment of the present application.

Alternatively, the computer-executable instructions in the embodiments of the present application may be referred to as application program codes, which are not particularly limited in the embodiments of the present application.

In a specific implementation, as an embodiment, the log processing device may include a plurality of processors, such as processor 901 and processor 902 in fig. 9. Each of these processors may be a single-core (single-CPU) processor or may be a multi-core (multi-CPU) processor. A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

In a specific implementation, as an embodiment, the log processing apparatus may further include an output device 905 and an input device 906. The output device 905 communicates with the processor 901 and may display information in a variety of ways. The input device 906, in communication with the processor 901, may receive input of a target object in a variety of ways. For example, the input device 906 may be a mouse, a touch screen device, a sensing device, or the like.

The log processing device described above may be a general purpose device or a special purpose device. In a specific implementation, the log processing device may be a server, a terminal, or the like, or a device having a similar structure in fig. 9. The embodiment of the application is not limited to the type of the log processing device.

Note that the processor 901 in fig. 9 may cause the log processing apparatus to execute the method in the method embodiment corresponding to fig. 3 to 4 by calling the computer-executable instructions stored in the memory 903.

In particular, the functions/implementation of the processing unit 802 in fig. 8 may be implemented by the processor 901 in fig. 9 invoking computer executable instructions stored in the memory 903. The function/implementation procedure of the acquisition unit 801 in fig. 8 can be implemented by the communication interface 904 in fig. 9.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of elements is merely a logical functional division, and there may be additional divisions of actual implementation, e.g., multiple elements or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The above-described embodiments may be implemented in whole or in part by software, hardware, firmware, or any combination thereof, and when implemented in software, may be implemented in whole or in part in the form of a computer program product.

The computer program product includes one or more computer instructions. When the computer-executable instructions are loaded and executed on a computer, the processes or functions in accordance with embodiments of the present application are fully or partially produced. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). Computer readable storage media can be any available media that can be stored by a computer or data storage devices such as servers, data centers, etc. that contain an integration of one or more available media. Usable media may be magnetic media (e.g., floppy disks, hard disks, magnetic tape), optical media (e.g., DVD), or semiconductor media (e.g., SSD)), or the like.

The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims (11)

1. A method of log processing, comprising:

acquiring a service request, wherein the service request comprises context information when the service request is currently executed;

acquiring target parameters from the context information, wherein the target parameters are used for indicating object conditions of target objects when the service request is executed and/or service related conditions of the service request;

and adding the target parameters into a log header, and adding the log header added with the target parameters into a log main body to obtain a target log file.

2. The method according to claim 1, wherein the method further comprises:

and calling a target printing function based on the context information to respond to the target printing function, wherein the target printing function is used for printing the target log file.

3. The method according to claim 2, wherein the method further comprises:

acquiring a log identifier from the target log file, wherein the log identifier is used for indicating whether the target log file is subjected to dyeing treatment or not;

the calling the target printing function based on the context information comprises the following steps:

and calling a corresponding target printing function according to the context information based on the log identification.

4. A method according to claim 3, wherein the target print function comprises a log print function, and the calling the target print function corresponding to the log print result according to the context information based on the log identification comprises:

when the log mark indicates that the target log file is subjected to dyeing treatment, determining that the target log file is a dyeing log;

and when the target log file is the dyeing log, calling the dyeing log printing function based on the context information.

5. A method according to claim 3, wherein said calling a corresponding target print function according to said context information based on said log identity comprises:

when the log mark indicates that the target log file is not dyed, determining that the target log file is a non-dyed log;

and calling a general log printing function based on the context information when the target log file is a non-staining log.

6. The method according to any one of claims 1 to 5, wherein adding the log header to which the target parameter is added to the log body to obtain the target log file includes:

and splicing the log header added with the target parameters before the log main body to obtain a target log file.

7. The method according to any one of claims 2 to 5, further comprising:

after printing the target log file based on the target print function, the context information is deleted.

8. A log processing apparatus, comprising:

the system comprises an acquisition unit, a processing unit and a processing unit, wherein the acquisition unit is used for acquiring a service request, and the service request comprises context information when the service request is currently executed;

the processing unit is used for acquiring target parameters from the context information, wherein the target parameters are used for indicating the object condition of a target object when the service request is sent and/or the service related condition of the service request;

and the processing unit is used for adding the target parameters into the log header, and adding the log header added with the target parameters into the target main body to obtain the target log file.

9. A log processing apparatus, comprising: an input/output (I/O) interface, a processor, and a memory, the memory having program instructions stored therein;

the processor is configured to execute program instructions stored in a memory to perform the method of any one of claims 1 to 7.

10. A computer readable storage medium comprising instructions which, when run on a computer device, cause the computer device to perform the method of any of claims 1 to 7.

11. A computer program product comprising instructions which, when run on a computer device, cause the computer device to perform the method of any of claims 1 to 7.