A method of log processing and related apparatus

Abstract

Embodiments of the present application disclose a log processing method and related device, which can solve the problem of repeated recording of a large amount of redundant information, and in the case of log information change, it is not necessary to modify each log point, so that the recording logic of the entire log file is more clear, and subsequent maintenance of the log file is facilitated. The method comprises: obtaining a service request, the service request comprising context information at the time of executing the service request; obtaining a target parameter from the context information, the target parameter being used to indicate an object condition of a target object at the time of executing the service request and / or a service related condition of the service request; adding the target parameter to a log header, and adding the log header with the added target parameter in a log body to obtain a target log file.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a log processing method and related apparatus. Background Technology

[0002] Internet services and applications, as well as various electronic devices, all generate logs during runtime. These logs primarily record the time, events, and custom log content defined by the business side at specific points in the program's execution. They can record critical service runtime events, laying the foundation for subsequent troubleshooting or understanding the service's operational status.

[0003] In related solutions, if complete log content needs to be printed during the execution of business requests, the necessary log information must be manually appended to the log content. For example, in business scenarios such as coroutines, each time an input / output request or network request is executed, the currently executing business logic may be switched to another logic flow. If complete object information is only printed at the beginning of the remote procedure call (RPC) execution, it is highly likely that when the logic flow switches back, the current object information cannot be seen from the log content, i.e., it is impossible to see which object the executed logic flow was targeting. In this case, it is necessary to manually append the object information from each request execution to the log content to complete the log printing.

[0004] However, the current processing method requires concatenating all information into the log content each time a request is executed, which easily leads to a large amount of redundant and duplicated information. Moreover, if additional log information needs to be added, modifications must be made at each log entry point, resulting in a lot of redundant information in the entire printed log file, which is not conducive to the subsequent maintenance of the log file. Summary of the Invention

[0005] This application provides a log processing method and related apparatus that can solve the problem of repeated recording of a large amount of redundant information. Moreover, when the log information changes, it is not necessary to modify it at every log entry point, making the recording logic of the entire log file clearer and facilitating the subsequent maintenance of the log file.

[0006] In a first aspect, embodiments of this application provide a log processing method. The method includes: obtaining a business request, the business request including context information at the time of execution of the business request; obtaining a target parameter from the context information, the target parameter indicating the object status of the target object at the time of execution of the business request and / or the business-related information of the business request; adding the target parameter to a log header, and adding the log header with the target parameter to the log body to obtain a target log file.

[0007] Secondly, embodiments of this application provide a log processing apparatus. The log processing apparatus includes an acquisition unit and a processing unit. The acquisition unit acquires a business request, which includes context information about the current execution of the business request. The processing unit acquires target parameters from the context information. These target parameters indicate the object status of the target object and / or the business-related information at the time of the business request. The processing unit adds the target parameters to a log header and appends the log header with the target parameters to the target body, thereby obtaining a target log file.

[0008] In some possible implementations, the processing unit is also used to: invoke a target printing function based on context information, in response to which the target printing function is used to print to a target log file.

[0009] In some possible implementations, the processing unit is also used to: obtain a log identifier from the target log file, the log identifier being used to indicate whether the target log file has been colored; and, based on the log identifier, call the corresponding target printing function according to the context information.

[0010] In some other possible implementations, the target printing function includes a coloring log printing function. The processing unit is used to: determine that the target log file is a coloring log when the log identifier indicates that the target log file has been colored; and, if the target log file is a coloring log, call the coloring log printing function based on context information.

[0011] In some other possible implementations, the processing unit is used to: determine that the target log file is an uncolored log file when the log identifier indicates that the target log file has not been colored; and when the target log file is an uncolored log file, call a general log printing function based on context information.

[0012] In some other possible implementations, the processing unit is used to append the log header of the target parameter to the log body to obtain the target log file.

[0013] In some other possible implementations, the processing unit is also used to delete context information after the target printing function has printed the target log file.

[0014] A third aspect of this application provides a log processing apparatus, including: a memory, an input / output (I / O) interface, and a processor. The memory stores program instructions. The processor executes the program instructions in the memory to perform the log processing method corresponding to the embodiment of the first aspect described above.

[0015] A fourth aspect of this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method corresponding to the embodiments of the first aspect described above.

[0016] The fifth aspect of this application provides a computer program product containing instructions that, when run on a computer or processor, causes the computer or processor to execute the method described above for performing the implementation method of the first aspect.

[0017] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0018] In this embodiment, a business request is obtained, which includes context information for the current execution of the business request. Target parameters are then obtained from this context information. These target parameters indicate the object request and / or business-related information of the target object during the execution of the business request. This allows the target parameters to be added to the log header, and the log header with the added target parameters to the log body, resulting in a target log file. In other words, this embodiment only requires adding the target parameters for different business scenarios to the log header and concatenating the log header to the log body to obtain the log file. It eliminates the need to concatenate all information into the log body each time a business request is executed, thus solving the problem of redundant information recording. Furthermore, it eliminates the need to modify every log entry point when log information changes, making the recording logic of the entire log file clearer and facilitating subsequent maintenance of the log file. Attached Figure Description

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

[0020] Figure 1 This diagram illustrates the code for concatenating log information in an existing solution.

[0021] Figure 2 A schematic diagram of the log processing framework provided in an embodiment of this application is shown;

[0022] Figure 3 A flowchart of a log processing method provided in an embodiment of this application is shown;

[0023] Figure 4 This document illustrates pseudocode diagrams showing the context management module processing business requests according to an embodiment of this application.

[0024] Figure 5 This document illustrates pseudocode diagrams showing the log output module setting the log header according to an embodiment of this application.

[0025] Figure 6 This document illustrates a pseudocode diagram of log file recording provided in an embodiment of this application.

[0026] Figure 7 This illustration shows a schematic diagram of the output of the target log file provided in an embodiment of this application;

[0027] Figure 8 A schematic diagram of the log processing apparatus provided in an embodiment of this application is shown;

[0028] Figure 9 A schematic diagram of the hardware structure of the log processing device provided in the embodiments of this application is shown. Detailed Implementation

[0029] This application provides a log processing method and related apparatus that can solve the problem of repeated recording of a large amount of redundant information. Moreover, when the log information changes, it is not necessary to modify it at every log entry point, making the recording logic of the entire log file clearer and facilitating the subsequent maintenance of the log file.

[0030] It is understood that in the specific embodiments of this application, data such as user information are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0031] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0032] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that implementations of the application described herein can be implemented, for example, in sequences other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] In the relevant solutions, during the execution of business requests, the necessary log information needs to be manually appended to the log content in order to print the complete log content. Taking a business request to change a username as an example... Figure 1 The diagram illustrates the code for concatenating log information in an existing solution. For example... Figure 1 As shown, each time a business request to change a username is executed, the currently executing business logic may be switched to another logic flow. For example, the currently executing business logic `log_debug("change user name,seq:%s,user_id:%s,new_name"%s", current_rpc.seq,current_user.user_id,new_name)` may be switched to the business logic `log_debug("query sameuser name,seq:%s,user_id:%s,new_name"%s",current_rpc.seq,current_user.user_id,new_name)`. However, if the complete object information is only printed at the beginning of the RPC execution, it is highly likely that when the logic flow switches back, the current object information (e.g., current_user.user_id, new_name, etc.) will not be visible in the log content, meaning it will be impossible to see which object the executed logic flow was targeting. At this point, it is necessary to manually append object information such as the object ID and object name of the current object to the log content for each request to complete the printing of the log content.

[0034] However, the current processing method requires concatenating all information to the log content each time a request is executed, which easily leads to the repeated recording of a large amount of redundant information. For example, Figure 1The information for objects such as current_rpc.seq, current_user.user_id, and new_name shown in the example is recorded repeatedly. Furthermore, if other log information needs to be updated, modifications must be made at every log entry point, resulting in a large amount of redundant information in the entire printed log file, which is detrimental to subsequent maintenance of the log file.

[0035] Based on this, in order to solve the technical problems described above, embodiments of this application provide a log processing method. This method can be applied to servers, terminal devices, and other devices; specific applications are not limited thereto. Illustratively, the application of the log processing method in a server is used as an example for illustration. Figure 2 A schematic diagram of the log processing framework provided in an embodiment of this application is shown. Figure 2 As shown, the server may include a context management module and a log output module. The context management module is primarily used to acquire business requests and add context information about the current execution of the business request to the fixed execution flow within the business logic of that request, thereby retrieving target parameters from the context information. It should be understood that the described context information can be interpreted as the environment parameters at the time of executing the business request. The business logic in this context management module is generally the outermost abstract logic of all business processes within that business request; that is, each business process is initiated and executed by this context management module.

[0036] The described log output module is mainly used to add the corresponding target parameters to the log header, and then add the log header to the original log body to obtain the corresponding target log file. For example, this log output module can be used to identify various business scenarios and then concatenate different parameter values ​​into the original log body according to different business scenarios.

[0037] It should be noted that the above are the main Figure 2 This explanation primarily uses a server as the execution entity, but in practical applications, other types of execution entities may also be used, and this application does not specify any limitations. Furthermore, the described server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services, etc., and this application does not specify any limitations. In addition, the above... Figure 1 The business request to modify the username shown is merely an illustrative description. In actual applications, it could be other business requests, which are not specifically limited in this application.

[0038] The following describes a log processing method provided by an embodiment of this application with reference to the accompanying drawings. Figure 3 A flowchart illustrating a log processing method provided in an embodiment of this application is shown. Figure 3As shown, the log processing method may include the following steps:

[0039] 301. Obtain the business request. The business request includes the context information of the current execution of the business request.

[0040] In this example, context information can be understood as the environment information at the time of executing the business request. The context information may differ depending on the specific business request being executed. For example, context information could be the execution time monitoring record of the current RPC being executed by the process, callback functions that need attention, business-related global parameters, etc., which are not specifically limited in this application. Furthermore, the business request could also be... Figure 1 The business request to modify the username shown could also be a business request to retrieve the Moments feed of an object, or a team-up request in a virtual game, etc. This application does not make any specific limitations.

[0041] 302. Obtain the target parameters from the context information. The target parameters are used to indicate the object status of the target object and / or the business-related information of the business request when executing the business request.

[0042] In this example, the target parameter can be understood as the information that needs to be focused on when executing the business request. For example, the target parameter may indicate one or more of the following: the object information of the target object when executing the business request, and the business-related information of the business request. The target parameters that need to be focused on may differ for different business scenarios. For instance, when responding to a business request event from an object, such as when an object clicks a button in a software or application, or when an object requests to access a webpage, the log file needs to print the object's identity (ID), username, and other object information that generated the business request, as well as the business-defined business-related information such as the RPC ID. Alternatively, when responding to a business request event from another service, the log file also needs to print which servers the business request originated from, the RPC ID, and other business-related information.

[0043] It should be noted that, in addition to the RPC ID, the business-related information may also include, but is not limited to, in-process resource usage, such as the central processing unit (CPU) and memory. This application does not impose any limitations on this. Furthermore, the object information described for the target object may include, in addition to the object ID and username, object location information, etc. This application does not impose any specific limitations on this.

[0044] For example, taking the executing entity as Figure 2Taking the server shown as an example, the business request can be obtained through the context management module within that server. For example, Figure 4 This illustration shows pseudocode of the context management module processing business requests according to an embodiment of this application. Figure 4 As shown, before processing any business logic, the process in the context management module first enters the function "process_task(seq): ctx = set_ctx(req)". Here, req represents the task parameters to be processed, and ctx is a global data structure describing the current process's business environment and parameters. At this point, the context management module can set the context information for the current process executing the business request based on its business environment and parameters. This ensures the business request includes the context information, allowing global variables to identify the environment in which the process executes the request, facilitating the acquisition of relevant target parameters during subsequent task processing. In some possible examples, the context management module can also execute specific business logic, such as transmitting the context information to the log output module, which then performs operations like concatenating target parameters and printing log files.

[0045] 303. Add the target parameter to the log header, and then add the log header with the target parameter to the log body to obtain the target log file.

[0046] In this example, after obtaining the target parameter from the context information, the target parameter can be added to the log header without needing to add it in every business logic step. Thus, after obtaining the log header with the target parameter added, it can be appended to the log body to obtain the target log file. For example, the log header with the target parameter added can be concatenated before the log body to obtain the target log file.

[0047] 304. Call the target print function based on context information in response to the target print function, which is used to print to the target log file.

[0048] In this example, after obtaining the target log file, the target log file can also be printed. For instance, the context information can be used to determine which logging module is being used for the current target log file, i.e., which target printing function is being called. The system then responds to the called target printing function and uses that function to print the target log file.

[0049] For example, different types of log printing functions can be called for different types of log files. For instance, a log identifier can be obtained from the target log file, indicating whether the target log file has been stained. Then, based on this log identifier and context information, the corresponding target printing function is called. For example, if the log identifier indicates that the target log file has been stained, the target log file can be determined to be a stained log. Then, when the target log file is stained, the stained log printing function is called based on the context information. The described stained log can be understood as marking log files generated by a specific object as stained. Subsequent log files of a specified level generated for the behavior of that object will be printed, facilitating troubleshooting in certain production environments. For example, since debug logging is generally not enabled in production environments, but in some business scenarios it is necessary to investigate abnormal business situations of an object, it is necessary to stain the debug-level log files generated by that object to facilitate subsequent anomaly investigation.

[0050] Similarly, when the log identifier indicates that the target log file has not been colored, it can be determined that the target log file is an uncolored log. Then, when the target log file is an uncolored log, the general log printing function is called based on the context information, and the log file of the uncolored log is printed based on the general log printing function.

[0051] For example, after printing to the target log file based on the target print function, this context information can also be deleted. For instance, from the aforementioned... Figure 4 It can also be seen that after the context management module completes the execution of business logic, it can also clear the current context information through the code "clear_ctx()", which can avoid the phenomenon that the environment information is confused when processing the next task, resulting in the execution error of the business logic.

[0052] For example, taking the executing entity as Figure 2 Taking the server shown as an example, the target parameter can be added to the log header and appended to the log body through the server's log output module. For example, Figure 5 This illustration shows pseudocode of the log output module setting the log header according to an embodiment of this application. Figure 5As shown, the log output module can set target parameters such as user.id, user.name, and team.id in the log header for different business request scenarios, and then append this header before the log body to obtain the log file 'content'. Then, when printing the log file 'content', the corresponding log printing function can be called based on context information. For example, if the log file 'content' is a stained log, the `do_print_dyeing_log(content')` function can be called; or if the log file 'content' is a non-stained log, the `do_print_common_log(content')` function can be called. It should be noted that... Figure 5 The business requests and printing functions shown are merely illustrative descriptions. In actual applications, there may be other requests and printing functions, which are not specifically limited in this application.

[0053] In this embodiment, since the business request includes context information about the current execution of the business request, the target parameter can be obtained from the context information by acquiring the business request. This target parameter indicates the object request of the target object and / or the business-related information of the business request when executing the business request. Thus, the target parameter can be added to the log header, and the log header with the target parameter added can be added to the log body to obtain the target log file. In other words, in this embodiment, only the target parameters for different business scenarios need to be added to the log header, and the log header concatenated to the log body to obtain the log file. It is not necessary to concatenate all the information to the log body every time a business request is executed, thereby solving the problem of redundant information recording. Moreover, if the log information changes, it is not necessary to modify it at every log point, making the recording logic of the entire log file clearer and facilitating subsequent maintenance of the log file. For example, Figure 6 A pseudocode diagram illustrating the log file recording provided in an embodiment of this application is shown. For example... Figure 6 As shown above, Figure 1 Taking the illustrated business scenario as an example, after applying the log processing method provided in this application, it is only necessary to add the target parameter to the log header and add the corresponding log header before the log body; it is not necessary to add the target parameter at every log entry point. Additionally, regarding... Figure 6 The output method of the target log file shown in the figure can also be referred to Figure 7 The output diagram of the target log file is shown for reference; further details will not be provided here.

[0054] The foregoing primarily describes the solutions provided by the embodiments of this application from a methodological perspective. It is understood that to achieve the above functions, corresponding hardware structures and / or software modules are included to execute each function. Those skilled in the art should readily recognize that, based on the modules and algorithm steps described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0055] This application embodiment can divide the device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0056] The log processing apparatus in the embodiments of this application will now be described in detail. Figure 8 This is a schematic diagram of one embodiment of the log processing apparatus provided in this application. Figure 8 As shown, the log processing device may include an acquisition unit 801 and a processing unit 802. The acquisition unit 801 acquires a business request, which includes context information for the current execution of the business request. The processing unit 802 acquires target parameters from the context information. These target parameters indicate the object status of the target object and / or the business-related information at the time of the business request. The processing unit 802 adds the target parameters to the log header and appends the log header with the target parameters to the target body, thus obtaining the target log file.

[0057] In some possible implementations, the processing unit 802 is also configured to: invoke a target printing function based on context information, in response to which the target printing function is used to print a target log file.

[0058] In some other possible implementations, the processing unit 802 is also used to: obtain a log identifier from the target log file, the log identifier being used to indicate whether the target log file has been colored; and, based on the log identifier, call the corresponding target printing function according to the context information.

[0059] In some other possible implementations, the target printing function includes a coloring log printing function. The processing unit 802 is configured to: determine that the target log file is a coloring log when the log identifier indicates that the target log file has been colored; and, when the target log file is a coloring log, invoke the coloring log printing function based on context information.

[0060] In some other possible implementations, the processing unit 802 is used to: determine that the target log file is an uncolored log when the log identifier indicates that the target log file has not been colored; and call a general log printing function based on context information when the target log file is an uncolored log.

[0061] In some other possible implementations, the processing unit 802 is used to append the log header of the target parameter to the log body to obtain the target log file.

[0062] In some other possible implementations, the processing unit 802 is also used to delete context information after the target printing function has printed the target log file.

[0063] The log processing device in the embodiments of this application has been described above from the perspective of modular functional entities. The log processing device in the embodiments of this application will now be described below from the perspective of hardware processing. Figure 9 This is a schematic diagram of the log processing device provided in an embodiment of this application. The log processing device can vary considerably depending on its configuration or performance. The log processing device may include at least one processor 901, a communication line 907, a memory 903, and at least one communication interface 904.

[0064] The processor 901 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (server IC), or one or more integrated circuits used to control the execution of the program of the present application.

[0065] Communication line 907 may include a path for transmitting information between the aforementioned components.

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

[0067] The memory 903 can be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions. The memory can exist independently and be connected to the processor via communication line 907. The memory can also be integrated with the processor.

[0068] The memory 903 stores computer execution instructions for implementing the scheme of this application, and its execution is controlled by the processor 901. The processor 901 executes the computer execution instructions stored in the memory 903, thereby implementing the log processing method provided in the above embodiments of this application.

[0069] Optionally, the computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

[0070] In a specific implementation, as one example, the log processing device may include multiple processors, for example... Figure 9 Processors 901 and 902 are described in the text. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. A processor here may refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0071] In a specific implementation, as one embodiment, the log processing device may further include an output device 905 and an input device 906. The output device 905 communicates with the processor 901 and can display information in various ways. The input device 906 communicates with the processor 901 and can receive input from the target object in various ways. For example, the input device 906 may be a mouse, a touch screen device, or a sensing device, etc.

[0072] The aforementioned log processing device can be a general-purpose device or a dedicated device. In specific implementations, the log processing device can be a server, a terminal, or something similar. Figure 9 A similar structure to the one described in this application. The embodiments of this application do not limit the type of log processing device.

[0073] It should be noted that Figure 9 The processor 901 can invoke computer execution instructions stored in memory 903 to cause the log processing device to perform actions such as... Figures 3 to 4 The method in the corresponding method embodiment.

[0074] Specifically, Figure 8The function / implementation process of the processing unit 802 in the middle can be achieved through Figure 9 The processor 901 in the memory calls computer execution instructions stored in the memory 903 to achieve this. Figure 8 The function / implementation process of the acquisition unit 801 can be achieved through... Figure 9 It is implemented using the 904 communication interface.

[0075] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0076] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0077] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0078] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0079] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0080] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0081] The above embodiments can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, they can be implemented in whole or in part in the form of a computer program product.

[0082] A computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, they generate, in whole or in part, the processes or functions according to embodiments of this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., SSDs), etc.

[0083] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A log processing method, characterized in that, include: Obtain a business request, the business request including context information at the time of executing the business request; Obtain the target parameter from the context information. The target parameter is used to indicate the object status of the target object and / or the business-related status of the business request when executing the business request. The target parameter is added to the log header, and the log header with the target parameter is added to the log body to obtain the target log file; The target print function is invoked based on the context information, in response to which the target print function is used to print the target log file.

2. The method according to claim 1, characterized in that, The method further includes: Obtain a log identifier from the target log file, the log identifier being used to indicate whether the target log file has been colored. The step of calling the target printing function based on the context information includes: Based on the log identifier, the corresponding target printing function is invoked according to the context information.

3. The method according to claim 2, characterized in that, The target printing function includes a colored log printing function. The step of calling the corresponding target printing function based on the log identifier and the context information includes: When the log identifier indicates that the target log file has been stained, the target log file is determined to be a stained log. When the target log file is the colored log, the colored log printing function is called based on the context information.

4. The method according to claim 2, characterized in that, The step of calling the corresponding target printing function based on the log identifier and the context information includes: When the log identifier indicates that the target log file has not been stained, the target log file is determined to be an unstained log. When the target log file is a non-colored log, the general log printing function is called based on the context information.

5. The method according to any one of claims 1 to 4, characterized in that, The step of adding the target parameter to the log header to obtain the target log file includes: The target log file is obtained by appending the log header with the target parameters to it before the log body.

6. The method according to any one of claims 1 to 4, characterized in that, The method further includes: After printing the target log file based on the target printing function, the context information is deleted.

7. A log processing device, characterized in that, include: An acquisition unit is used to acquire a business request, the business request including context information when the business request is currently being executed; The processing unit is configured to obtain target parameters from the context information, wherein the target parameters are used to indicate the object status of the target object and / or the business-related status of the business request when the business request is made; The processing unit is used to add the target parameter to the log header and add the log header with the target parameter to the target body to obtain the target log file; The processing unit is further configured to call a target printing function based on the context information, in response to the target printing function, which is used to print the target log file.

8. The apparatus according to claim 7, characterized in that, The processing unit is further configured to obtain a log identifier from the target log file, the log identifier being used to indicate whether the target log file has been colored. Based on the log identifier, the corresponding target printing function is invoked according to the context information.

9. The apparatus according to claim 8, characterized in that, The target printing function includes a coloring log printing function; the processing unit is configured to determine that the target log file is a coloring log when the log identifier indicates that the target log file has been colored; and to call the coloring log printing function based on the context information when the target log file is the coloring log.

10. The apparatus according to claim 8, characterized in that, The processing unit is configured to determine that the target log file is an uncolored log file when the log identifier indicates that the target log file has not been colored; and to call a general log printing function based on the context information when the target log file is an uncolored log file.

11. The apparatus according to any one of claims 7 to 10, characterized in that, The processing unit is used to append the log header with the target parameters added to it before the log body to obtain the target log file.

12. The apparatus according to any one of claims 7 to 10, characterized in that, The processing unit is further configured to delete the context information after printing the target log file based on the target printing function.

13. A log processing device, characterized in that, include: Input / output (I / O) interface, processor, and memory, wherein program instructions are stored in the memory; The processor is used to execute program instructions stored in the memory to perform the method as described in any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed on a computer device, cause the computer device to perform the method as described in any one of claims 1 to 6.

15. A computer program product, characterized in that, The computer program product includes instructions that, when executed on a computer device, cause the computer device to perform the method as described in any one of claims 1 to 6.

Images