Log recording method and device

Abstract

The embodiment of the present application provides a method and device for logging, including: in response to a call request, using a first tool class to call a remote service interface through a unified entry for calling multiple remote service interfaces and a servlet container on the server side; for the unified entry, using the first tool class to obtain a request parameter object in the call request; for the remote service interface, using the first tool class to obtain a result data object corresponding to the call request returned by the server side; for the unified entry, using the first tool class to call a second tool class, and logging the request parameter object and the result data object according to a predetermined unified log processing logic through the second tool class; the first tool class is a dynamic proxy class created based on a dynamic proxy in JAVA reflection, and the second tool class is a logging tool class created based on a dynamic proxy in JAVA reflection.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of data processing, and in particular to a log recording method and device. Background Art

[0002] Thrift is a remote procedure call framework that includes serialization functions and supports service communication. The framework is a client and server (Client / Server Structs, C / S) structure.

[0003] In some scenarios, when the Thrift framework is applied, the log record is to add corresponding log printing logic to each entry of the remote service call on the calling side and each service interface on the server side, recording the request parameters corresponding to the remote service interface and the result data returned by the remote service interface. Add log printing logic to each service interface on the server side to record the parameters requested by the calling side and the result data returned by the server. In this way, when calling the entry of the remote service, adding log printing logic to each entry of the remote service call on the calling side is cumbersome, and the efficiency of log recording is low. When modifying the log printing logic, it is also necessary to modify the log printing logic of each entry of the remote service call and the log printing logic of each service interface one by one, which has low management efficiency and cannot record and manage logs in a centralized and efficient manner. Summary of the invention

[0004] The purpose of the embodiments of the present application is to provide a log recording method and device to solve the problems of cumbersome log recording operations and low log recording efficiency and management efficiency.

[0005] In order to solve the above technical problems, the embodiments of the present application are implemented as follows:

[0006] In a first aspect, an embodiment of the present application provides a log recording method, the method comprising:

[0007] In response to a call request, a first tool class is used to call a remote service interface through a unified entry for calling multiple remote service interfaces and a servlet container on the server side; for the unified entry, the first tool class is used to obtain a request parameter object in the call request; for the remote service interface, the first tool class is used to obtain a result data object corresponding to the call request returned by the server side; for the unified entry, the first tool class is used to call a second tool class, and the request parameter object and the result data object are logged through the second tool class according to a predetermined unified log processing logic; the first tool class is a dynamic proxy class created based on a dynamic proxy in JAVA reflection, and the second tool class is a logging tool class created based on a dynamic proxy in JAVA reflection.

[0008] In a second aspect, an embodiment of the present application provides a log recording device, the device comprising:

[0009] In response to the call request of the unified entrance of multiple remote services, based on the created servelt container, the Servlet request object instance and the Servlet response object instance are obtained; the logging tool class is called through the Servlet request object instance and the Servlet response object instance; the logging tool class is used to obtain the request parameter object from the Servlet request object instance and the result data object from the Servlet response object instance; the request parameter object and the result data object are logged using the logging tool class according to the unified log processing logic predetermined for the multiple remote service interfaces.

[0010] In a third aspect, an embodiment of the present application provides an electronic device, including a processor, a communication interface, a memory and a communication bus; wherein the processor, the communication interface and the memory communicate with each other through the bus; the memory is used to store computer programs; the processor is used to execute the programs stored in the memory to implement the method steps of log recording as in the first aspect or the second aspect.

[0011] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method steps of log recording in the first aspect or the second aspect are implemented.

[0012] In a fifth aspect, an embodiment of the present application provides a chip, the chip including a processor and a communication interface, the communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the log recording method of the first aspect or the second aspect.

[0013] The technical solution provided by the embodiment of the present application includes: in response to a call request, using a first tool class to call a remote service interface through a unified entry for calling multiple remote service interfaces and a servlet container on the server side; for the unified entry, using the first tool class to obtain a request parameter object in the call request; for the remote service interface, using the first tool class to obtain a result data object corresponding to the call request returned by the server side; for the unified entry, using the first tool class to call a second tool class, and logging the request parameter object and the result data object according to a predetermined unified log processing logic through the second tool class; the first tool class is a dynamic proxy class created based on a dynamic proxy in JAVA reflection, and the second tool class is a logging tool class created based on a dynamic proxy in JAVA reflection.

[0014] Therefore, the entrance for calling multiple remote service interfaces is a unified entrance. The first tool class can be used to call the remote service interface through the unified entrance and the servlet container on the server side, and the request parameter object and result data object at the unified entrance can be obtained. At the unified entrance, the second tool class records the request parameter object and result data object according to the predetermined unified log processing logic. The operation is simple, and the logs are recorded and managed in a centralized and efficient manner. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0016] Figure 1 An overall architecture diagram of a log record provided in an embodiment of the present application;

[0017] Figure 2 A first flow chart of a log recording method provided in an embodiment of the present application;

[0018] Figure 3 A second flow chart of a log recording method provided in an embodiment of the present application;

[0019] Figure 4 A third flow chart of a log recording method provided in an embodiment of the present application;

[0020] Figure 5 A schematic diagram of the first module composition of a log recording device provided in an embodiment of the present application;

[0021] Figure 6 A schematic diagram of a second module composition of a log recording device provided in an embodiment of the present application;

[0022] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The embodiments of the present application provide a method and device for log recording, which simplifies the operation of log recording and improves the efficiency of log recording and management.

[0024] In order to enable those skilled in the art to better understand the technical solutions in the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0025] In some scenarios, when the Thrift framework is applied, logging is done by adding corresponding log printing logic to each entry of the remote service call on the calling side and each service interface on the server side, recording the request parameters corresponding to the remote service interface and the result data returned by the remote service interface. Log printing logic is added to each service interface on the server side to record the parameters requested by the calling side and the result data returned by the server.

[0026] In this way, when there are too many entrances for calling remote services and service interfaces on the server side, it is cumbersome to add log printing logic to each entrance for calling remote services on the calling side and to add log printing logic to each service interface on the server side. When the log printing logic needs to be modified, the log printing logic of each entrance for calling remote services and the log printing logic of each service interface need to be modified one by one, which makes it impossible to record and manage logs in a centralized and efficient manner.

[0027] In order to solve the above technical problems, the embodiments of the present application provide a log recording method and device. The technical solution provided by the embodiments of the present application is described below in conjunction with relevant drawings.

[0028] like Figure 1 As shown, this is an overall architecture diagram of a log record provided in an embodiment of the present application. The overall architecture diagram of a log record provided in an embodiment of the present application uses JAVA reflection dynamic proxy at the calling end and rewrites the Servlet container at the server end to implement centralized and efficient logging and log management at the calling end and the server end in the Thrift framework.

[0029] For the calling side, the details are as follows.

[0030] In a possible implementation, the embodiment of the present application uses JAVA reflection dynamic proxy to unify the entry of the remote service interface of the calling server in the Thrift framework, and adds a predetermined unified log processing logic. For the calling end, JAVA reflection dynamic proxy is used to create two classes ThriftLogProxy.java (first tool class) and LoggerUtility.java (second tool class), LoggerUtility.java is a created logging tool class to implement log recording, and ThriftLogProxy.java is an implementation class of the dynamic proxy, which is used to call LoggerUtility.java in the rewritten Invoke function.

[0031] When calling the remote service interface of the server, an instance of the client proxy class is created through "(IQthVehicleService.Iface)new ThriftLogProxy().getProxy(client)" (target tool function) in the dynamic proxy class, and the remote service interface is called based on the created client proxy class instance. Specifically, it can be expressed as: IQthVehicleService.IfaceclientProxy=(IQthVehicleService.Iface)newThriftLogProxy().getProxy(client).

[0032] Among them, "IQthVehicleService.IfaceclientProxy" represents the instance of the created client proxy class. <qtvehicle>resultList=clientProxy.queryJyVehicle(jyVehicleRequest),"List <qtvehicle>"resultList" indicates the result of calling the remote service interface, and "clientProxy.queryJyVehicle(jyVehicleRequest)" indicates the interface name of the remote service interface called.

[0033] For example, Figure 1 As shown, on the calling end, (IQthVehicleService.Iface)newThriftLogProxy().getProxy(client) is used to create three instances of the client proxy class (instances of the client proxy class), namely, instance one of the client proxy class "clientProxyA(parame 1)", instance two of the client proxy class "clientProxyB(parame 2)", and instance three of the client proxy class "clientProxyC(parame 3)".

[0034] The instances of the three client proxy classes request to call the remote service interface through the unified entrance and the Servlet container on the server side, which are remote service interface one "IQthVehicleService->A", remote service interface two "IQthVehicleService->B" and remote service interface three "IQthVehicleService->C". When requesting to call the remote service interface in the instance of the client proxy class, its request parameter object includes but is not limited to the interface name of the remote service interface called, the requested service type, etc. At the unified entrance, ThriftLogProxy.java obtains the request parameter objects requested by the instances of the three client proxy classes on the calling side, as well as the result data object returned by the server in response to the request parameter object, and passes the result data object of the request parameter object to the log processing function of LoggerUtility.java. The log processing function parses the result data object of the request parameter object and writes it to the log file or database according to the defined log format.

[0035] For the server, the details are as follows.

[0036] When the caller calls the remote service interface through the servelt container, the class of the servelt container can be rewritten. In the service function, the ServletRequest (Servlet request object instance) and ServletResponse (Servlet response object instance) are backed up to solve the problem that the stream data in the ServletRequest (Servlet request object instance) and ServletResponse (Servlet response object instance) cannot be read repeatedly. After the backup, the request parameter object and the result data object can be read from the data stream of the Servlet request object instance and the Servlet response object instance.

[0037] The specific steps for backing up ServletRequest (Servlet request object instance) and ServletResponse (Servlet response object instance) are as follows:

[0038] Create two new classes in the target folder (such as util package), WrappedHttpServletRequest (the first backup class) and WrappedHttpServletResponse (the second backup class), use WrappedHttpServletRequest to back up ServletRequest, and use WrappedHttpServletResponse to back up ServletResponse.

[0039] Furthermore, for the servlet container, a new ThriftBaseServlet can be created as the parent class of all servlet containers, and two attributes are defined in the parent class, namely facadeName and processor. The facadeName attribute is the interface name of the remote service interface, and the processor is the processor instance corresponding to the interface name.

[0040] On the server side, a new logging tool class named LoggerUtility.java is created corresponding to multiple remote service interfaces. The thriftServletLog function is defined in the logging tool class. The function is used as a log processing function to parse request parameter objects and result data objects and to record logs.

[0041] When the calling end initiates a call request, the created servlet container uniformly inherits the ThriftBaseServlet parent class, and calls the two attributes of the parent class in the service function of the constructor of the newly created servlet container for initialization. The interface name of the remote service interface is determined according to the facadeName defined in the parent class, and then the corresponding Servlet request object instance and Servlet response object instance are obtained according to the interface name. Then, in the rewritten service function, the backup Servlet request object instance and Servlet response object instance are used as parameters to call the thriftServletLog function in the logging tool class. The thriftServletLog function obtains the request parameter object and result data object from the stream data of the Servlet request object instance and the Servlet response object instance, and writes them to the log file according to the predetermined unified log format.

[0042] It is worth noting that the log printing logic of the calling end and the log printing logic of the server end can be the same or different, and the embodiments of the present application are not limited thereto.

[0043] Through the technical solution disclosed in the embodiment of the present application, the entrance for calling the remote service interface at the calling end is a unified entrance, a unified log processing logic is added at the unified entrance, and the multiple service interfaces at the service end adopt the servlet container to unify the log processing logic. Therefore, there is no need to add the log processing logic one by one for each entrance and service interface for calling the remote service interface, the operation is simple, and the efficiency of recording logs is high. In addition, when managing (such as modifying) the log processing logic, it is only necessary to manage the log processing logic at the unified entrance of the calling end and the unified log processing logic corresponding to the multiple service interfaces, the management is simple, and the log management efficiency is improved. In addition, at the calling end and the service end, the log record of the calling end and the log record of the service end can be performed separately, that is, the log record of the calling end is realized by the first tool class and the second tool class of the unified entrance of the calling end, and the log record of the service end is realized by the servlet container and the log record tool class of the service end, which improves the flexibility of log record.

[0044] like Figure 2 As shown, the embodiment of the present application provides a log recording method, the execution subject of the method may be a terminal, and the log recording method may specifically include the following steps S201-S203:

[0045] In S201: in response to a call request, the remote service interface is called by using a first tool class through a unified entry for calling multiple remote service interfaces and a servlet container on the server side.

[0046] Specifically, the call request is a request initiated by the terminal (calling end) to call the remote service interface. The first tool class is a dynamic proxy class created based on the dynamic proxy in JAVA reflection, such as the above-mentioned ThriftLogProxy.java, which is used to unify the entrances of multiple remote service interfaces of the calling end, that is, the entrances for calling multiple remote service interfaces are the same. The calling end calls the remote service interface through the entrance and the servlet container of the server.

[0047] In one possible implementation, S201 includes: creating an instance of a client proxy class through a target tool function in a first tool class; based on the created instance of the client proxy class, calling the remote service interface through a unified entry for calling multiple remote service interfaces and a server-side servlet container.

[0048] Specifically, the target tool function in the first tool class can be (IQthVehicleService.Iface)new ThriftLogProxy().getProxy(client), which is used to create an instance of the client proxy class. The instance of the client proxy class is used to call the remote service interface through the above-mentioned unified entry and the server-side servlet container.

[0049] In S202, for the unified entry, the first tool class is used to obtain the request parameter object in the call request; for the remote service interface, the first tool class is used to obtain the result data object corresponding to the call request returned by the server.

[0050] Specifically, the request parameter objects in the call request include but are not limited to the interface name of the remote service interface, the type of requested service, etc. The result data objects include but are not limited to the service data provided by the server for the type of requested service, and the time it takes for the server to process the call request (the time from when the server receives the call request to when it sends the result data object to the caller).

[0051] In S203, for the unified entry, the first tool class is used to call the second tool class, and the request parameter object and the result data object are logged according to the predetermined unified log processing logic through the second tool class.

[0052] Specifically, the first tool class is a dynamic proxy class created based on the dynamic proxy in JAVA reflection, and the second tool class is a logging tool class created based on the dynamic proxy in JAVA reflection.

[0053] In a possible implementation, using the first tool class to call the second tool class includes: using the first tool class to call the second tool class in an overridden Invoke function.

[0054] Specifically, the second tool class can be called in JAVA by means of Invoke, and the second tool class performs log recording according to a predetermined unified log processing logic.

[0055] In a possible implementation, the log processing logic includes parsing the request parameter object and the result data object and recording the parsed request parameter object and the result data object to a log file. Then, logging the request parameter object and the result data object according to the predetermined unified log processing logic by the second tool class includes: parsing the request parameter object and the result data object into a unified format by the second tool class; and recording the request parameter object and the result data object parsed into the unified format into the log file according to a predefined log format.

[0056] Specifically, for request parameter objects and result data objects, the data formats may not be uniform. To facilitate log recording, the request data objects and result data objects can be parsed into a uniform format. The predefined log format can be customized by the user according to actual conditions, such as the type of data contained in the recorded log, the line break format in the log, etc.

[0057] In one possible manner, the log processing logic can also be managed, such as modification, deletion, addition, and other management operations.

[0058] Through the technical solution disclosed in the embodiment of the present application, the entrance for calling multiple remote service interfaces is a unified entrance. The first tool class can be used to call the remote service interface through the unified entrance and the servlet container on the server side, and the request parameter object and the result data object at the unified entrance can be obtained. At the unified entrance, the second tool class records the request parameter object and the result data object according to the predetermined unified log processing logic. When managing (such as modifying) the log processing logic, it is only necessary to modify the log processing logic at the unified entrance and other management operations. The operation is simple, and logs can be recorded and managed in a centralized and efficient manner.

[0059] like Figure 3 As shown, the embodiment of the present application provides a log recording method, and the execution subject of the method can be a server, wherein the server can be an independent server or a server cluster composed of multiple servers. The log recording method can specifically include the following steps S301-S304:

[0060] In S301, in response to a call request of a unified entrance of multiple remote services, a Servlet request object instance and a Servlet response object instance are obtained based on the created servlet container.

[0061] In a possible implementation, S301 includes: determining interface information defined in a parent class of the created servlet container; and acquiring a Servlet request object instance and a Servlet response object instance based on the interface information.

[0062] Specifically, the Servlet request object instance and the Servlet response object instance are object instances that come with the service function. The embodiment of the present application can read the request parameter object and the call parameter object correspondingly from the data stream of the Servlet request object instance and the Servlet response object instance. The parent class of the created servelt container can be ThriftBaseServlet. Two attributes are defined in ThriftBaseServlet, namely facadeName and processor, where facadeName is the interface name of the remote service interface called, and processor is the instance of the processor corresponding to the interface name. The Servlet request object instance and the Servlet response object instance are obtained according to the interface name of the facadeName, and processed by the processor.

[0063] In S302, the logging tool class is called through the Servlet request object instance and the Servlet response object instance.

[0064] In a possible implementation, S302 includes: in the rewritten service function, using the backup Servlet request object instance and the backup Servlet response object instance as parameters to call a logging tool class.

[0065] Specifically, in order to avoid the situation where data in the Servlet request object instance and the backup Servlet response object instance cannot be read repeatedly, a first backup class corresponding to the Servlet request object instance and a second backup class corresponding to the Servlet response object instance can be created in advance; the first backup class is used to back up the Servlet request object instance, and the second backup class is used to back up the Servlet response object instance.

[0066] The first backup class and the second backup class may be newly created classes in the util package, such as the first backup class may be WrappedHttpServletRequest, and the second backup class may be WrappedHttpServletResponse. WrappedHttpServletRequest backs up the Servlet request object instance, and WrappedHttpServletResponse backs up the Servlet response object instance.

[0067] In S303, the logging tool class is used to obtain the request parameter object from the Servlet request object instance, and the result data object from the Servlet response object instance.

[0068] In a possible implementation, S303 includes: using the log processing function defined in the log recording tool class to obtain the request parameter object from the Servlet request object instance, and to obtain the result data object from the Servlet response object instance.

[0069] Specifically, the logging tool class may be the LoggerUtility class, and the log processing function defined in the LoggerUtility class may be the thriftServletLog function. After obtaining the Servlet request object instance and the Servlet response object instance through the interface information defined in the parent class of the above servelt container, the thriftServletLog function is called with the Servlet request object instance and the Servlet response object instance as parameters in the rewritten service function, and the thriftServletLog function obtains the request parameter object from the Servlet request object instance and the result data object from the Servlet response object instance.

[0070] Furthermore, after obtaining the Servlet request object instance and the Servlet response object instance through the interface information defined in the parent class of the above servelt container, the thriftServletLog function is called with the backup Servlet request object instance and the backup Servlet response object instance as parameters in the rewritten service function, and the thriftServletLog function obtains the request parameter object from the backup Servlet request object instance and the result data object from the backup Servlet response object instance. This avoids the problem that the data in the Servlet request object instance and the Servlet response object instance cannot be read repeatedly.

[0071] In S304, the request parameter object and the result data object are logged using a logging tool class according to a unified log processing logic predetermined for a plurality of remote service interfaces.

[0072] In a possible implementation, S304 includes: writing the request parameter object and the result data object into a log file according to a predefined log format by using a log tool class.

[0073] Specifically, the predefined log format can be defined by the user according to actual conditions, and the embodiments of the present application are not limited thereto. In addition, the same parts of the above embodiments can be referenced to each other, and the embodiments of the present application will not be repeated here.

[0074] In one possible manner, the log processing logic can also be managed, such as modification, deletion, addition, and other management operations.

[0075] Through the technical solution disclosed in the embodiment of the present application, in multiple remote service interfaces, based on the created servlet container, the Servlet request object instance and the Servlet response object instance can be obtained, and then the logging tool class is called through the Servlet request object instance and the Servlet response object instance, and the request parameter object and the result data object are obtained from the Servlet request object instance and the Servlet response object instance by using the logging tool class, and the logging tool class performs logging according to the predetermined unified log processing logic. There is no need to add log printing logic to each remote service interface one by one. In addition, when managing (such as modifying) the log printing logic, only the log printing logic is managed, which is simple to operate and improves the efficiency of log recording and management.

[0076] like Figure 4 As shown, the embodiment of the present application provides a method for logging, and the execution subject of the method can be a server, wherein the server can be an independent server or a server cluster composed of multiple servers. The method for logging can specifically include the following steps S400-S404:

[0077] In S400, a pre-created first backup class corresponding to the Servlet request object instance and a second backup class corresponding to the Servlet response object instance are determined; the Servlet request object instance is backed up using the first backup class, and the Servlet response object instance is backed up using the second backup class.

[0078] Specifically, the first backup class and the second backup class can be newly created classes in the util package, such as the first backup class can be WrappedHttpServletRequest, and the second backup class can be WrappedHttpServletResponse. WrappedHttpServletRequest backs up the Servlet request object instance, and WrappedHttpServletResponse backs up the Servlet response object instance.

[0079] In S401, in response to a call request of a unified entrance of multiple remote services, a Servlet request object instance and a Servlet response object instance are obtained based on the created servlet container.

[0080] In S402, the logging tool class is called through the Servlet request object instance and the Servlet response object instance.

[0081] In S403, the logging tool class is used to obtain the request parameter object from the Servlet request object instance, and the result data object from the Servlet response object instance.

[0082] In S404, the request parameter object and the result data object are logged using a logging tool class according to a unified log processing logic predetermined for a plurality of remote service interfaces.

[0083] In a possible implementation, the log processing logic may also be managed, such as modification, deletion, addition, and other management operations.

[0084] It is worth noting that S401 to S404 in the embodiment of the present application have the same or similar implementation methods as the above-mentioned S301 to S304, which can refer to each other, and the embodiment of the present application will not be repeated here.

[0085] Through the technical solution provided by the embodiment of the present application, in multiple remote service interfaces, based on the created servlet container, the Servlet request object instance and the Servlet response object instance can be obtained, and then the logging tool class is called through the Servlet request object instance and the Servlet response object instance, and the request parameter object and the result data object are obtained from the Servlet request object instance and the Servlet response object instance by using the logging tool class, and the logging tool class performs logging according to the predetermined unified log processing logic. There is no need to add log printing logic to each remote service interface one by one. In addition, when managing (such as modifying) the log printing logic, only the log printing logic is managed, which is simple to operate and improves the efficiency of log recording and management.

[0086] In addition, backing up the Servlet request object instance and the Servlet response object instance avoids the situation where the data in the Servlet request object instance and the Servlet response object instance cannot be read repeatedly, further improving the efficiency of log recording.

[0087] Corresponding to the log recording method provided in the above embodiment, based on the same technical concept, the embodiment of the present application also provides a log recording device, Figure 5 A schematic diagram of the module composition of a log recording device provided in an embodiment of the present application, wherein the log recording device is used to execute Figure 2 Describes the logging method, such as Figure 5 As shown, the log recording device includes: a calling module 501, an acquiring module 502, and a recording module 503.

[0088] The calling module 501 is used to respond to the calling request and use the first tool class to call the remote service interface through the unified entrance for calling multiple remote service interfaces and the servlet container on the server side; the obtaining module 502 is used to use the first tool class to obtain the request parameter object in the calling request for the unified entrance; for the remote service interface, use the first tool class to obtain the result data object corresponding to the calling request returned by the server side; the recording module 503 is used to use the first tool class to call the second tool class for the unified entrance, and log the request parameter object and the result data object according to the predetermined unified log processing logic through the second tool class; the first tool class is a dynamic proxy class created based on the dynamic proxy in JAVA reflection, and the second tool class is a logging tool class created based on the dynamic proxy in JAVA reflection.

[0089] Through the technical solution provided by the embodiment of the present application, the entrance for calling multiple remote service interfaces is a unified entrance. The first tool class can be used to call the remote service interface through the unified entrance and the servlet container on the server side, and the request parameter object and result data object at the unified entrance can be obtained. At the unified entrance, the second tool class records the request parameter object and the result data object according to the predetermined unified log processing logic, which is simple to operate, and records and manages logs in a centralized and efficient manner.

[0090] In one possible implementation, the calling module 501 is also used to create an instance of the client proxy class through the target tool function in the first tool class; based on the created instance of the client proxy class, the remote service interface is called through a unified entry for calling multiple remote service interfaces and a server-side servlet container.

[0091] In a possible implementation, the recording module 503 is further configured to use the first tool class to call the second tool class in the overwritten Invoke function.

[0092] In a possible implementation, the recording module 503 is further used to parse the request parameter object and the result data object into a unified format using the second tool class; and record the request parameter object and the result data object parsed into the unified format into a log file according to a predefined log format.

[0093] Corresponding to the log recording method provided in the above embodiment, based on the same technical concept, the embodiment of the present application also provides a log recording device, Figure 6 A schematic diagram of the module composition of a log recording device provided in an embodiment of the present application, wherein the log recording device is used to execute Figure 3 and Figure 4 Describes the logging method, such as Figure 6 As shown, the log recording device includes: a first acquisition module 601, a calling module 602, a second acquisition module 603 and a recording module 604.

[0094] The first acquisition module 601 is used to respond to the call request of the unified entrance of multiple remote services, and obtain the Servlet request object instance and the Servlet response object instance based on the created servelt container; the calling module 602 is used to call the logging tool class through the Servlet request object instance and the Servlet response object instance; the second acquisition module 603 is used to use the logging tool class to obtain the request parameter object from the Servlet request object instance and the result data object from the Servlet response object instance; the recording module 604 is used to log the request parameter object and the result data object according to the unified log processing logic predetermined corresponding to the multiple remote service interfaces using the logging tool class.

[0095] Through the technical solution provided by the embodiment of the present application, in multiple remote service interfaces, based on the created servlet container, the Servlet request object instance and the Servlet response object instance can be obtained, and then the logging tool class is called through the Servlet request object instance and the Servlet response object instance, and the request parameter object and the result data object are obtained from the Servlet request object instance and the Servlet response object instance by using the logging tool class, and the logging tool class performs logging according to the predetermined unified log processing logic. There is no need to add log printing logic to each remote service interface one by one. In addition, when managing (such as modifying) the log printing logic, only the log printing logic is managed, which is simple to operate and improves the efficiency of log recording and management.

[0096] In a possible implementation, the method further includes:

[0097] A determination module is used to determine a pre-created first backup class corresponding to a Servlet request object instance and a second backup class corresponding to a Servlet response object instance; a backup module is used to back up the Servlet request object instance using the first backup class and back up the Servlet response object instance using the second backup class.

[0098] In a possible implementation, the first acquisition module 601 is further used to determine the interface information defined in the parent class of the created servlet container; and acquire the Servlet request object instance and the Servlet response object instance based on the interface information.

[0099] In a possible implementation, the calling module 602 is further used to call the logging tool class by taking the backup Servlet request object instance and the backup Servlet response object instance as parameters in the rewritten service function.

[0100] In a possible implementation, the second acquisition module 603 is further configured to obtain a request parameter object from a Servlet request object instance and obtain a result data object from a Servlet response object instance using a log processing function defined in a log recording tool class.

[0101] In a possible implementation, the recording module 604 is further configured to write the request parameter object and the result data object into a log file according to a predefined log format using a log tool class.

[0102] The logging device provided in the embodiment of the present application can implement each process in the embodiment corresponding to the above-mentioned logging method, and will not be described again here to avoid repetition.

[0103] It should be noted that the log recording device provided in the embodiment of the present application and the log recording method provided in the embodiment of the present application are based on the same inventive concept, so the specific implementation of this embodiment can refer to the implementation of the aforementioned log recording method, and the repeated parts will not be repeated.

[0104] Corresponding to the log recording method provided in the above embodiment, based on the same technical concept, the embodiment of the present application also provides an electronic device, which is used to execute the above log recording method. Figure 7 A schematic diagram of the structure of an electronic device for implementing various embodiments of the present invention is shown in FIG. Figure 7 As shown. The electronic device may have relatively large differences due to different configurations or performances, and may include one or more processors 701 and memory 702, and the memory 702 may store one or more storage applications or data. Among them, the memory 702 can be a temporary storage or a permanent storage. The application stored in the memory 702 may include one or more modules (not shown in the figure), and each module may include a series of computer executable instructions in the electronic device. Furthermore, the processor 701 can be configured to communicate with the memory 702 to execute a series of computer executable instructions in the memory 702 on the electronic device. The electronic device may also include one or more power supplies 703, one or more wired or wireless network interfaces 704, one or more input and output interfaces 705, and one or more keyboards 706.

[0105] In this embodiment, the electronic device includes a processor, a communication interface, a memory and a communication bus; wherein the processor, the communication interface and the memory communicate with each other through the bus; the memory is used to store computer programs; the processor is used to execute the programs stored in the memory to implement the following method steps:

[0106] In response to a call request, a first tool class is used to call a remote service interface through a unified entry for calling multiple remote service interfaces and a servlet container on the server side; for the unified entry, the first tool class is used to obtain a request parameter object in the call request; for the remote service interface, the first tool class is used to obtain a result data object corresponding to the call request returned by the server side; for the unified entry, the first tool class is used to call a second tool class, and the request parameter object and the result data object are logged through the second tool class according to a predetermined unified log processing logic; the first tool class is a dynamic proxy class created based on a dynamic proxy in JAVA reflection, and the second tool class is a logging tool class created based on a dynamic proxy in JAVA reflection.

[0107] Or in response to a call request from a unified entry of multiple remote services, based on the created servelt container, obtain the Servlet request object instance and the Servlet response object instance; call the logging tool class through the Servlet request object instance and the Servlet response object instance; use the logging tool class to obtain the request parameter object from the Servlet request object instance, and obtain the result data object from the Servlet response object instance; use the logging tool class to log the request parameter object and the result data object according to the unified log processing logic predetermined for the multiple remote service interfaces.

[0108] In a specific embodiment, the embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0109] In response to a call request, a first tool class is used to call a remote service interface through a unified entry for calling multiple remote service interfaces and a servlet container on the server side; for the unified entry, the first tool class is used to obtain a request parameter object in the call request; for the remote service interface, the first tool class is used to obtain a result data object corresponding to the call request returned by the server side; for the unified entry, the first tool class is used to call a second tool class, and the request parameter object and the result data object are logged through the second tool class according to a predetermined unified log processing logic; the first tool class is a dynamic proxy class created based on a dynamic proxy in JAVA reflection, and the second tool class is a logging tool class created based on a dynamic proxy in JAVA reflection.

[0110] Or in response to a call request from a unified entry of multiple remote services, based on the created servelt container, obtain the Servlet request object instance and the Servlet response object instance; call the logging tool class through the Servlet request object instance and the Servlet response object instance; use the logging tool class to obtain the request parameter object from the Servlet request object instance, and obtain the result data object from the Servlet response object instance; use the logging tool class to log the request parameter object and the result data object according to the unified log processing logic predetermined for the multiple remote service interfaces.

[0111] In a specific embodiment, the embodiment of the present application provides a chip, the chip includes a processor and a communication interface, the communication interface is coupled to the processor, and the processor is used to run a program or instruction to implement the following steps:

[0112] In response to a call request, a first tool class is used to call a remote service interface through a unified entry for calling multiple remote service interfaces and a servlet container on the server side; for the unified entry, the first tool class is used to obtain a request parameter object in the call request; for the remote service interface, the first tool class is used to obtain a result data object corresponding to the call request returned by the server side; for the unified entry, the first tool class is used to call a second tool class, and the request parameter object and the result data object are logged through the second tool class according to a predetermined unified log processing logic; the first tool class is a dynamic proxy class created based on a dynamic proxy in JAVA reflection, and the second tool class is a logging tool class created based on a dynamic proxy in JAVA reflection.

[0113] Or in response to a call request from a unified entry of multiple remote services, based on the created servelt container, obtain the Servlet request object instance and the Servlet response object instance; call the logging tool class through the Servlet request object instance and the Servlet response object instance; use the logging tool class to obtain the request parameter object from the Servlet request object instance, and obtain the result data object from the Servlet response object instance; use the logging tool class to log the request parameter object and the result data object according to the unified log processing logic predetermined for the multiple remote service interfaces.

[0114] It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, devices, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0115] The present invention is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0116] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0117] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0118] In a typical configuration, an electronic device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0119] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0120] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0121] It should also be noted that the term "includes", "comprising" or any other variation thereof is intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of further restrictions, an element defined by the sentence "comprising a ..." does not exclude the existence of other identical elements in the process, method, commodity or device including the element.

[0122] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, devices or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0123] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included within the scope of the claims of the present application.< / qtvehicle> < / qtvehicle>

Claims

1. A logging method, characterized in that: The method comprises: In response to the call request, the remote service interface is called by using the first tool class through a unified entry for calling multiple remote service interfaces and a servlet container on the server side, wherein the unified entry is an entry in the Thrift framework for calling the remote service interface on the server side and is added with a predetermined unified log processing logic; For the unified entry, the first tool class is used to obtain the request parameter object in the call request; for the remote service interface, the first tool class is used to obtain the result data object corresponding to the call request returned by the server; For the unified entry, the first tool class is used to call the second tool class, and the request parameter object and the result data object are logged according to a predetermined unified log processing logic through the second tool class; The first tool class is a dynamic proxy class created based on the dynamic proxy in JAVA reflection, and the second tool class is a logging tool class created based on the dynamic proxy in JAVA reflection; The logging of the request parameter object and the result data object according to a predetermined unified log processing logic by the second tool class includes: Using the second tool class, the request parameter object and the result data object are parsed into a unified format; The request parameter objects and result data objects parsed into a unified format are recorded in the log file according to the predefined log format.

2. The method according to claim 1, characterized in that The method of using the first tool class to call a plurality of remote service interfaces through a unified entry and a server-side servlet container includes: Creating an instance of the client proxy class through the target tool function in the first tool class; Based on the created instance of the client proxy class, the remote service interface is called through the unified entry for calling multiple remote service interfaces and the server-side servlet container.

3. The method according to claim 1, characterized in that The using the first tool class to call the second tool class includes: The first tool class is used to call the second tool class in the rewritten Invoke function.

4. A logging method, characterized in that: The method comprises: In response to a call request of a unified entry of multiple remote services, a Servlet request object instance and a Servlet response object instance are obtained based on the created servlet container, wherein the call request instructs the caller to use a first tool class to call a remote service interface through a unified entry for calling multiple remote service interfaces and a servlet container on the server side, wherein the unified entry is an entry in a Thrift framework for calling the remote service interface of the server side and is added with a predetermined unified log processing logic; Calling the logging tool class through the Servlet request object instance and the Servlet response object instance; Using the logging tool class, obtain a request parameter object from the Servlet request object instance, and obtain a result data object from the Servlet response object instance; For the request parameter object and the result data object, log the request parameter object and the result data object using the log recording tool class according to the unified log processing logic predetermined for the plurality of remote service interfaces; The method of using the logging tool class to obtain a request parameter object from the Servlet request object instance and obtaining a result data object from the Servlet response object instance includes: Using the log processing function defined in the log recording tool class, obtain the request parameter object from the Servlet request object instance, and obtain the result data object from the Servlet response object instance; The step of performing log recording on the request parameter object and the result data object by using the log recording tool class according to the unified log processing logic predetermined for the plurality of remote service interfaces comprises: The request parameter object and the result data object are written into a log file according to a predefined log format using the log tool class.

5. The method according to claim 4, characterized in that Before obtaining the Servlet request object instance and the Servlet response object instance based on the created servlet container in response to the call request of the unified entrance of multiple remote services, the method further includes: Determine a pre-created first backup class corresponding to the Servlet request object instance and a second backup class corresponding to the Servlet response object instance; The Servlet request object instance is backed up using the first backup class, and the Servlet response object instance is backed up using the second backup class.

6. The method according to claim 5, characterized in that The step of obtaining the Servlet request object instance and the Servlet response object instance based on the created servlet container includes: Determine the interface information defined in the parent class of the created servlet container; Acquire the Servlet request object instance and the Servlet response object instance based on the interface information; The calling of the logging class through the Servlet request object instance and the Servlet response object instance includes: In the rewritten service function, the backup Servlet request object instance and the backup Servlet response object instance are used as parameters to call the logging tool class.

7. A device for recording a log, characterized in that: include: A calling module, used to call the remote service interface in response to the calling request, using the first tool class through a unified entry for calling multiple remote service interfaces and a servlet container on the server side, wherein the unified entry is an entry in the Thrift framework for calling the remote service interface on the server side, and is added with a predetermined unified log processing logic; An acquisition module, used for acquiring the request parameter object in the calling request by using the first tool class for the unified entry; For the remote service interface, using the first tool class to obtain the result data object corresponding to the call request returned by the server; A recording module, for calling a second tool class by using the first tool class for the unified entry, and performing log recording on the request parameter object and the result data object according to a predetermined unified log processing logic through the second tool class; The first tool class is a dynamic proxy class created based on the dynamic proxy in JAVA reflection, and the second tool class is a logging tool class created based on the dynamic proxy in JAVA reflection; The recording module is further configured to utilize the second tool class to parse the request parameter object and the result data object into a unified format; The request parameter objects and result data objects parsed into a unified format are recorded in the log file according to the predefined log format.

8. A log recording device, characterized in that: include: A first acquisition module is used to respond to a call request of a unified entry of multiple remote services, and based on the created servlet container, acquire a Servlet request object instance and a Servlet response object instance, wherein the call request instructs the caller to use a first tool class to call a remote service interface through a unified entry for calling multiple remote service interfaces and a servlet container on the server side, wherein the unified entry is an entry in a Thrift framework for calling the remote service interface of the server side, and a predetermined unified log processing logic is added; A calling module, used for calling a logging tool class through the Servlet request object instance and the Servlet response object instance; A second acquisition module is used to use the logging tool class to acquire a request parameter object from the Servlet request object instance and to acquire a result data object from the Servlet response object instance; A recording module, used for recording the request parameter object and the result data object by using the logging tool class according to a unified log processing logic predetermined for a plurality of remote service interfaces; The second acquisition module is further configured to obtain a request parameter object from the Servlet request object instance and obtain a result data object from the Servlet response object instance by using a log processing function defined in the log recording tool class; The recording module is further specifically used to write the request parameter object and the result data object into a log file according to a predefined log format using the log tool class.

Images