CN114896130A

CN114896130A - Log processing method, device, server and storage medium

Info

Publication number: CN114896130A
Application number: CN202210602026.8A
Authority: CN
Inventors: 康斌
Original assignee: Beijing Dajia Internet Information Technology Co Ltd
Current assignee: Beijing Dajia Internet Information Technology Co Ltd
Priority date: 2022-05-30
Filing date: 2022-05-30
Publication date: 2022-08-12

Abstract

The disclosure relates to a log processing method, a log processing device, a server and a storage medium, and relates to the technical field of computers. The method comprises the following steps: receiving an interface request, and generating a request identifier of the interface request, wherein the interface request comprises interface request parameters, and the interface request parameters are used for representing caller information of the interface request and interface information requested by the interface request; calling a pre-packaged log printing tool, wherein the log printing tool is used for indicating a use request identifier, an interface request parameter and an interface calling parameter to print log data; the interface calling parameter is used for representing the parameter used when the interface request is executed; the log data requested by the interface is printed based on the log print tool. The log data generated by the method is rich in content, the problem location is good, and the query convenience of the log data is improved.

Description

Log processing method, device, server and storage medium

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a log processing method and apparatus, a server, and a storage medium.

Background

Logging is an important approach to program debugging and problem location. For example, in the event of an error in calling a service through an interface, logging of service calls is critical to troubleshooting the problem.

In the related art, when generating a log record, usually only log details of a calling service can be generated. The log records generated by the method have single content.

Therefore, it is an urgent technical problem to design a new log generation method.

Disclosure of Invention

The disclosure provides a log processing method, a log processing device, a server and a storage medium, which are used for at least solving the problem of single content of log records in the related art. The technical scheme of the disclosure is as follows:

according to a first aspect of the embodiments of the present disclosure, there is provided a log processing method for a server, the method including: receiving an interface request, and generating a request identifier of the interface request, wherein the interface request comprises interface request parameters, and the interface request parameters are used for representing caller information of the interface request and interface information requested by the interface request; calling a pre-packaged log printing tool, wherein the log printing tool is used for indicating a use request identifier, an interface request parameter and an interface calling parameter to print log data; the interface calling parameter is used for representing the parameter used when the interface request is executed; the log data requested by the interface is printed based on the log print tool.

In one possible embodiment, invoking a pre-packaged journal printing tool includes: calling a pre-packaged log printing tool under the condition that the target parameter belongs to a preset printing parameter set; the target parameters include interface request parameters and/or interface call parameters.

In another possible embodiment, the printing the log data requested by the interface based on the log printing tool includes: under the condition that the server is determined to be configured with the self-defined log parameters, the log printing tool prints the log data requested by the interface based on the request identifier, the interface request parameters, the interface calling parameters and the self-defined log parameters; and under the condition that the server is determined not to be configured with the self-defined log parameters, the log printing tool prints the log data requested by the interface based on the request identifier, the interface request parameters, the interface calling parameters and default log parameters which are configured in advance by the log printing tool.

In another possible embodiment, the printing the log data requested by the interface based on the log printing tool includes: acquiring a current link node for executing an interface request; and under the condition that the current link node belongs to the preset printing link node set, the log printing tool prints the log data of the current link node requested by the interface based on the request identifier, the interface request parameter and the interface calling parameter.

In another possible embodiment, after printing log data requested by the interface based on the log printing tool, the method further includes: and returning request result information of the interface request to the caller, wherein the request result information comprises a request identifier and interface calling parameters.

In another possible embodiment, the log data includes log indexes and log details, and after the log data requested by the interface is printed based on the log printing tool, the method further includes: storing the log index in a first database; the time length of the first database for storing the log index is a first preset time length; storing the log details in a second database; the time length of the second database for storing the log details is a first preset time length.

In another possible embodiment, after the log data requested by the interface is printed based on the log printing tool, the method further includes: and storing the log data in a third database, wherein the time for storing the log data in the third database is a second preset time, and the second preset time is longer than the first preset time.

In another possible embodiment, storing the log details in a second database comprises: in the case that the request identification is not included in the second database, inserting the log details into the second database; in the case where the request identity is included in the second database, the log details are stored in the second database in the row in which the request identity is located.

In another possible embodiment, the method further comprises: receiving a first query request sent by a calling party, wherein the first query request comprises a query statement; the query statement comprises at least one of a request identifier, an interface request parameter and an interface calling parameter; inquiring a target log index corresponding to the query statement from the first database, and returning the target log index to the caller based on the first query request; receiving a second query request sent by a calling party, wherein the second query request comprises a target request identifier of an interface request to which a target log index belongs; and inquiring the target log details corresponding to the target request identification in the second database, and returning the target log details to the caller based on the second inquiry request.

According to a second aspect of the embodiments of the present disclosure, there is provided a log processing apparatus including: the receiving module is configured to execute receiving of the interface request and generate a request identifier of the interface request; the interface request includes an interface request parameter; the interface request parameter is used for representing caller information of the interface request and interface information requested by the interface request; a calling module configured to execute calling a pre-packaged log printing tool, wherein the log printing tool is used for indicating a use request identifier, an interface request parameter and an interface calling parameter to print log data; the interface calling parameter is used for representing the parameter used when the interface request is executed; and the log module is configured to execute the log printing tool based on the log data requested by the printing interface.

In one possible embodiment, the logging module is configured to perform: calling a pre-packaged log printing tool under the condition that the target parameter belongs to a preset printing parameter set; the target parameters include interface request parameters and/or interface call parameters.

In another possible embodiment, the log module is configured to perform: under the condition that the server is determined to be configured with the self-defined log parameters, the log printing tool prints the log data requested by the interface based on the request identifier, the interface request parameters, the interface calling parameters and the self-defined log parameters; and under the condition that the server is determined not to be configured with the self-defined log parameters, the log printing tool prints the log data requested by the interface based on the request identifier, the interface request parameters, the interface calling parameters and default log parameters pre-configured by the log printing tool.

In another possible implementation, the logging module is configured to perform: acquiring a current link node for executing an interface request; and under the condition that the current link node belongs to the preset printing link node set, the log printing tool prints the log data of the current link node requested by the interface based on the request identifier, the interface request parameter and the interface calling parameter.

In another possible implementation, the apparatus further includes a sending module configured to perform: after the log data requested by the interface is printed based on the log printing tool, request result information of the interface request is returned to the caller, and the request result information comprises a request identifier and an interface calling parameter.

In another possible implementation, the log data includes a log index and log details, and the apparatus further includes a storage module configured to perform: storing the log index in a first database; the time length of the first database for storing the log index is a first preset time length; storing the log details to a second database; the time length of the second database for storing the log details is a first preset time length.

In another possible embodiment, the storage module is further configured to perform: and storing the log data in a third database, wherein the time for storing the log data in the third database is a second preset time, and the second preset time is longer than the first preset time.

In another possible embodiment, the storage module is further configured to perform: in the case that the request identification is not included in the second database, inserting the log details into the second database; and under the condition that the request identification is included in the second database, storing the log details into a row of the second database where the request identification is located.

In another possible implementation, the apparatus further includes a query module configured to perform: receiving a first query request sent by a calling party, wherein the first query request comprises a query statement; the query statement comprises at least one of a request identifier, an interface request parameter and an interface calling parameter; inquiring a target log index corresponding to the query statement from the first database, and returning the target log index to the caller based on the first query request; receiving a second query request sent by a calling party, wherein the second query request comprises a target request identifier of an interface request to which a target log index belongs; and inquiring the target log details corresponding to the target request identification from the second database, and returning the target log details to the caller based on the second inquiry request.

According to a third aspect of the embodiments of the present disclosure, there is provided a server, including: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the method of the first aspect and any of its possible embodiments described above.

According to a fourth aspect of embodiments of the present disclosure, there is provided a computer-readable storage medium, wherein instructions, when executed by a processor of a server, enable the server to perform the method of any one of the above-described first aspects and any possible implementation thereof.

According to a fifth aspect of embodiments of the present disclosure, there is provided a computer program product comprising computer instructions which, when run on a server, cause the server to perform the information processing method of the first aspect and any of its possible implementations.

The technical scheme provided by the embodiment of the disclosure at least brings the following beneficial effects: after receiving the interface request, generating a request identifier of the interface request, thereby realizing the series connection of the logs on the link nodes of the interface request. Further, by packaging a log printing tool and calling the log printing tool to generate the link log, the link log is generated by bringing general information such as the request identifier, the object identifier, the caller identifier and the like, so that the function of expanding the link log is realized, the log query dimension is expanded, a user can perform log query through the information such as the request identifier, the object identifier, the caller identifier and the like, and the convenience and the accuracy of log query are improved. In addition, the time-consuming information of the link node is brought in the log, so that the user can know the execution condition of the interface request more completely.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the disclosure and are not to be construed as limiting the disclosure.

FIG. 1 is an architectural diagram illustrating one implementation environment in accordance with an exemplary embodiment;

FIG. 2 is a flow diagram illustrating a method of log processing in accordance with an exemplary embodiment;

FIG. 3 is a block diagram illustrating a method of log processing in accordance with an exemplary embodiment;

FIG. 4 is an architecture diagram illustrating a method of log processing in accordance with an exemplary embodiment;

FIG. 5 is a flow diagram illustrating another log processing method in accordance with an illustrative embodiment;

FIG. 6 is a flow diagram illustrating another log processing method in accordance with an illustrative embodiment;

FIG. 7 is an architecture diagram illustrating another log processing method in accordance with an exemplary embodiment;

FIG. 8 is a flow diagram illustrating another log processing method in accordance with an illustrative embodiment;

FIG. 9 is a block diagram illustrating another method of log processing in accordance with an illustrative embodiment;

FIG. 10 is a block diagram illustrating a log processing apparatus in accordance with an exemplary embodiment;

FIG. 11 is a block diagram illustrating a server in accordance with an example embodiment.

Detailed Description

In order to make the technical solutions of the present disclosure better understood by those of ordinary skill in the art, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

It should be noted that the terms "first," "second," and the like in the description and claims of the present disclosure and in the above-described drawings are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the disclosure described herein are capable of operation in sequences other than those illustrated or otherwise described herein. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

Before describing the information processing method provided by the present disclosure in detail, the application scenario, implementation environment and related elements related to the present disclosure are briefly described.

First, in order to facilitate understanding of the present application, the relevant elements involved in the present application will now be described.

Independent Software developer (Independent Software Vendors, ISV): in particular to enterprises specialized in development, production, sale and service of software, such as Microsoft (Microsoft), Oracle (Oracle) and the like.

In one embodiment, an ISV refers to a party invoking a client service in an open scenario, and needs to camp on as an ISV when interfacing to an open platform. Currently, two types of third party developers and merchant developers are supported, clients of the third party developers can be put on the shelf to a service market for selling, and the clients of the merchant developers are only used by the third party developers.

Gateway (Gateway): also known as internetwork connectors, protocol converters. The gateway realizes network interconnection above a network layer, is a complex network interconnection device and is only used for interconnection of two networks with different high-level protocols. The gateway can be used for interconnection of both wide area networks and local area networks. A gateway is a computer system or device that acts as a switch-operative. The gateway is a translator used between two systems that differ in communication protocol, data format or language, or even in an entirely different architecture. Specifically, the gateway repackages the received information to accommodate the needs of the destination system.

Full link: for a request sent by a requestor, it is generally necessary to perform multiple service calls through multiple nodes. The call link formed between nodes from the requester is called a full link.

Full link log (full link log): a log over the entire link for one request.

Application Programming Interface (API): are some predefined interfaces (e.g. functions, HTTP interfaces) or refer to conventions for the joining of different components of the software system. In one embodiment, it is used to provide a set of routines that applications and developers can access based on certain software or hardware without having to access source code or understand the details of the internal workings.

Universal Unique Identifier (UUID): is a standard for software construction and is part of the open software foundation organization in the field of distributed computing environments. The aim is to enable all elements in the distributed system to have unique identification information without specifying the identification information through a central control end. In this way, everyone can create a UUID that does not conflict with others. In such a case, the name duplication problem at the time of database creation does not need to be considered.

Hive: the Hadoop-based data warehouse tool is used for extracting, converting and loading data, and is a mechanism capable of storing, inquiring and analyzing large-scale data stored in Hadoop.

Ims (IP Multimedia subsystem) is an IP Multimedia system, a new form of Multimedia service, and can meet the requirements of more novel and diversified Multimedia services for end-users.

Uniform Resource Identifier (URI): the "name" of an IMS user in an IMS network, i.e. the identity of the IMS user.

Secondly, the application scenario related to the present disclosure is briefly introduced.

Logging is an important approach to program debugging and problem location. For example, in the event of an error in calling a service through an interface, logging of service calls is critical to problem location. In the related art, one service call request usually involves the call of a plurality of services, and when generating the log record of the service call, the log record is usually collected by the system of each service individually, and then the log of each service is stored separately. Due to the log generation mode, when the interface calling service has an error, log query needs to be performed on each service, and the time cost and the difficulty of the log query are very high.

In view of the above problems, the present disclosure provides a log processing method, which generates a request identifier of an interface request after receiving the interface request, thereby implementing concatenation of logs on link nodes of the interface request. Further, by packaging a log printing tool and calling the log printing tool to generate the link log, the link log is generated by bringing general information such as the request identifier, the object identifier, the caller identifier and the like, so that the function of expanding the link log is realized, the log query dimension is expanded, a user can perform log query through the information such as the request identifier, the object identifier, the caller identifier and the like, and the convenience and the accuracy of log query are improved. In addition, the time-consuming information of the link node is brought in the log, so that the user can know the execution condition of the interface request more completely.

Again, the following presents a brief description of an implementation environment (implementation architecture) to which the present disclosure relates.

The following briefly introduces an implementation environment (implementation architecture) related to the present disclosure, as shown in fig. 1, which illustrates a schematic diagram of an implementation environment to which the present disclosure is applicable. The implementation environment may include a server 110 and an electronic device 120, and the electronic device 120 may establish a connection with the server 110 through a network (wired network or wireless network).

The electronic device 120 is a device used by an interface caller. The caller (external user) of the interface completes the transmission of the interface request and the log query request using the electronic device 120. The electronic device 120 may be a mobile phone, a tablet computer, a notebook computer, a palm computer, a desktop computer, a portable computer, a vehicle-mounted terminal, a wearable device, and the like, which is not limited in this disclosure.

The server 110 is configured to process an interface request and a log query request. In some embodiments, the server 110 may be a single server, or may be a server cluster composed of multiple servers, which is not limited in this disclosure.

In one embodiment, the server 110 is an API gateway server that includes a gateway management domain, a gateway runtime domain, and a log center. The gateway management domain, the gateway operation domain and the log center may be independent servers, or may be different modules in one server.

For the convenience of understanding, the log processing method provided by the present disclosure is specifically described below with reference to the accompanying drawings.

Fig. 2 is a flow diagram illustrating a log processing method for the server 110 according to an example embodiment. As shown in fig. 2, the log processing method includes the steps of:

s201: receiving an interface request, and generating a request identifier of the interface request.

The interface request comprises interface request parameters, and the interface request parameters are used for representing caller information of the interface request and interface information requested by the interface request.

In one embodiment, the interface request parameters include one or more of an object identification (userId), a caller identification (appkey), and an interface path identification (uri). Wherein the object identifier is used for indicating the identifier of the object sending the interface request. Illustratively, the object identification includes a primary object identification primaryuserId and a secondary object identification userId. It should be noted that one object id may correspond to multiple slave object ids, and one slave object id only corresponds to one master object id.

In one embodiment, the interface request comprises an API request. For example, the API request may be a request for an API by an external user of the API gateway server. Wherein an external user (ISV) sends an interface request through a first electronic device. Alternatively, the API request may be a request by an internal user or business of the API gateway server to request the API. Wherein the internal user or service party may send the interface request through the second electronic device.

In one embodiment, a gateway run domain of the API gateway server receives the interface request and generates a globally unique request identification. Illustratively, the server may generate a request identification for the interface request based on the UUID. By generating the request identifier of the interface request based on the UUID, the problem of repeated request identifiers in a high-concurrency scene is avoided.

In one embodiment, the request identifies log data for each link node of the serial interface request. The link nodes comprise at least one of interface parameter input nodes, interface parameter output nodes, authentication parameter input nodes, authentication parameter output nodes, service parameter input nodes, service parameter output nodes, abnormal nodes and the like.

In one embodiment, the request identification may be a requestId, also known as sessionId or transactionId. Specifically, the logs of different link nodes of an interface Request can be concatenated by the requestId by passing through the link nodes by marking the X-Request-Id (X-Session-Id) in the interface Request header.

It should be noted that different interface requests have different request identifications. Different link nodes requested by an interface have the same request identity.

S202: and calling a pre-packaged log printing tool, wherein the log printing tool is used for indicating that log data is printed by using the request identifier, the interface request parameter and the interface calling parameter.

The interface calling parameter is used for representing the parameter used when the interface request is executed.

In one embodiment, the interface call parameters include one or more of time consuming information of the interface request, an error code, an error description, a log type identifier, request time information of the interface request, and the like.

Optionally, before S201, the log processing method further includes: and packaging a log printing tool, wherein the log printing tool is used for indicating parameters required to be carried when log data requested by a printing interface is printed, namely, the log data requested by the printing interface is the parameters required to be carried and indicated by the log printing tool.

In one embodiment, the log printing tool includes one or more of a request identification, an interface request parameter, an interface call parameter, and the like. Therefore, when the log printing tool is called to print log data of an interface request, one or more of a request identifier, an interface request parameter, an interface call parameter, and the like need to be printed at the same time. By packaging the log printing tool and calling the log printing tool when the log data requested by the interface is printed, the parameters in the log printing tool are printed in the log data, so that on one hand, the contents of the log data are enriched, and on the other hand, the query convenience is improved.

In one example, upon initialization of the gateway runtime domain, a pre-packaged log print tool is obtained from the gateway management domain.

In one embodiment, as shown in fig. 3, the internal user and/or the external user sends an interface request, for example, an API request, to the gateway runtime domain, and the gateway runtime domain generates a globally unique request identifier after receiving the interface request, and calls a pre-packaged log printing tool to print log data of the interface request.

S203: the log data requested by the interface is printed based on the log print tool.

In one embodiment, after a log printing tool packaged in advance is called, based on a parameter indicated by the log printing tool, a content corresponding to the parameter is obtained, and when log data requested by an interface is printed, the parameter and the content corresponding to the parameter are printed. For example, the parameters indicated by the log printing tool include a request identifier, an interface request parameter, and an interface call parameter, and at this time, the server prints log data requested by the interface based on the request identifier, the interface request parameter, and the interface call parameter.

In one embodiment, the log data includes a log index and log details. The server prints the log index based on the request identifier, the interface request parameter, the interface call parameter, and the content corresponding to the interface call parameter, respectively, in the log index.

It should be noted that the content corresponding to the parameter may be a value corresponding to the parameter, for example, the content corresponding to the time-consuming information requested by the interface is a duration.

In one embodiment, as shown in fig. 3, after the gateway runs the log data requested by the domain printing interface, the gateway sends the log data to the log center, so that the log center can store the log data by consuming the log data. In another embodiment, after the gateway runs the log data requested by the domain printing interface, the log data is sent to the kafka message, and the log data is stored by consuming the kafka message.

In an embodiment, the packaged log printing tool includes a plurality of printing parameters, for example, an object identifier, the caller identifier, an interface path identifier, a request identifier, time consumption information of an interface request, an error code, an error description, a log type, a time for printing the log data, and the like, and the server calls the packaged log printing tool, obtains a content corresponding to each printing parameter, and prints the log data.

Optionally, after S203, the log processing method further includes: and returning request result information of the interface request to the caller, wherein the request result information comprises interface calling parameters and a request identifier.

In the above embodiment, when the log data requested by the interface is printed, the interface calling parameter and the request identifier are printed at the same time, that is, the log data includes the interface calling parameter and the request identifier, and the request result information carrying the interface calling parameter is sent to the service calling party, so that the user can query the log data based on the interface calling parameter and the request identifier, thereby improving the convenience and accuracy of log query.

In the above embodiment, after receiving the interface request, a request identifier of the interface request is generated, and the request identifier is printed when the log data of the interface request is received, so that the log data on each link node of the interface request are connected in series, and further the log data of the full link node of the interface request can be queried through the request identifier. Furthermore, the log data requested by the interface is printed by calling the log printing tool packaged in advance, so that the printing parameters of the log data, such as the printing request identifier, the interface request parameter, the call receiving parameter and the like, can be expanded, on one hand, the content of the log data is enriched, and the problem positioning capability of the log data is improved. On the other hand, the query dimension of the log data is enlarged, so that a user can query the log through parameters such as a request identifier, an interface request parameter and a call receiving parameter, and the convenience and the accuracy of log query are improved. In addition, the method can improve data security, improve code multiplexing capability, avoid the need to care about specific implementation, and quickly and accurately call the printing parameters. In addition, the time-consuming information is included in the interface calling parameters, so that the execution condition of the interface request can be more comprehensively known, and the execution flow of the interface request can be further optimized.

Optionally, S202 includes: and calling a pre-packaged log printing tool under the condition that the target parameter belongs to a preset printing parameter set.

Wherein the target parameters comprise interface request parameters and/or interface calling parameters,

in one embodiment, the preset set of printing parameters may further include one or more of a request identification, an identification of a cluster to which the interface request belongs, and a device identification of the caller.

In one embodiment, the set of preset printing parameters includes an identification segment of the preset printing parameters. Wherein the identification segments for different parameters may be different. For example, the identifier segment of the caller device is 100-200, when the identifier of the caller device is 150, the identifier of the caller device belongs to the identifier segment of the caller device, and when the identifier of the caller device is 210, the identifier of the caller device does not belong to the identifier segment of the caller device. In addition, in the case that the preset printing parameter set includes a plurality of identification segments of the preset printing parameters, the log data of the interface request is printed only in the case that the identification of each target parameter of the interface request belongs to the identification segment corresponding to the preset printing parameter.

In one embodiment, in the case that the target parameter of the interface request belongs to the preset printing parameter set, the pre-packaged log printing tool is called, and the log data of the interface request is printed. And under the condition that the target parameter of the interface request does not belong to a preset log printing white list, only executing the task of the interface request, not calling a log printing tool packaged in advance and not printing log data of the interface request.

In one embodiment, the server obtains and stores the preset printing parameter set when initializing.

In one example, the server obtains a set of preset printing parameters entered by the provider or business of the API gateway.

In another example, as shown in fig. 3, the provider or the service side of the API gateway sets a preset printing parameter set on the gateway configuration domain, and the preset printing parameter set is read from the gateway configuration domain through kbus/task when the gateway operation domain is initialized. Further, under the condition that the provider or the service side of the API gateway updates the preset printing parameter set, the kbus/task reads the updated preset printing parameter set from the gateway configuration domain again, and replaces the preset printing parameter set before updating with the updated preset printing parameter set.

Before the API gateway server operates, a provider or a service side of the API gateway configures the API gateway server. The configuration of the API gateway may be performed on a gateway management domain.

In one embodiment, the API gateway configuration comprises an API configuration. For example, the contents of the API configuration are shown in table 1.

TABLE 1

In one embodiment, the API gateway configuration includes a parameter configuration. For example, the contents of the parameter configuration are shown in table 2.

TABLE 2

In the above embodiment, the log printing tool packaged in advance is called by setting that the target parameter of the interface request belongs to the preset printing parameter set, so that the interface request for printing the log data is subjected to multi-dimensional screening instead of printing logs of all interface requests, and the reduction of the printing workload of the log data is facilitated.

Optionally, S203 includes:

the method comprises the following steps: and under the condition that the server is determined to be configured with the self-defined log parameters, the log printing tool prints the log data requested by the interface based on the request identifier, the interface request parameters, the interface calling parameters and the self-defined log parameters.

In one embodiment, the server obtains and stores the custom log parameters when initializing.

In one example, the server obtains custom log parameters entered by the service or provider of the API gateway. In another example, a service side or provider of the API gateway sets custom log parameters on the gateway configuration domain, and the custom log parameters are read from the gateway configuration domain by kbus/task when the gateway operation domain is initialized. Further, under the condition that the service side updates the custom log parameters, the kbus/task reads the updated custom log parameters from the gateway configuration domain again.

In one embodiment, for illustration purpose, the API gateway server of the order is used, the interface entry is an order identifier (oid), and the interface exit includes structure information such as order basic information (orderBaseInfo), order commodity information (orderetminfo), order refund list (orderedundlist), order logistics information (orderlogisticsfnfo), order remarks (orderNote), order address (orderAddress), and order flag (orderFlag). Wherein, the most core field is orderBaseInfo, including: order payment time, order payment amount, order status, etc. Therefore, oid for interface in-referencing and orderBaseInfo for interface out-referencing are configured as custom log parameters.

It should be noted that when setting the custom log parameters, the core and non-sensitive field is typically set as the custom log parameters, such as order payment time, order payment amount, order status, and the like.

In one embodiment, in the case that a user-defined log parameter is configured in an interface (API), the user-defined log parameter and the content corresponding to the user-defined log parameter are printed to obtain log data. And obtaining the content corresponding to the user-defined log parameter from the interface request. In addition, the interface request parameter and its corresponding content, the interface call parameter and its corresponding content, and the request identifier are also printed.

Step two: and under the condition that the server is determined not to be configured with the self-defined log parameters, the log printing tool prints the log data requested by the interface based on the request identifier, the interface request parameters, the interface calling parameters and default log parameters which are configured in advance by the log printing tool.

In one embodiment, when the interface (API) does not configure the custom log parameter, a default log parameter configured in advance by the log printing tool and a content corresponding to the default log parameter are printed to obtain the log data. For example, the default log parameters include error code (result), error description (errMsg), and the like. In addition, the interface request parameter and its corresponding content, the interface call parameter and its corresponding content, and the request identifier are also printed.

In the embodiment, the log data is printed based on the self-defined log parameters under the condition that the server is configured with the self-defined log parameters, so that the log data content is printed according to actual requirements, the log data effectiveness is improved, and the log data printing workload is reduced.

Optionally, the step S203 includes: and obtaining a current link node executing the interface request, and printing the log data of the current link node requested by the interface by the log printing tool based on the request identifier, the interface request parameter and the interface calling parameter under the condition that the current link node belongs to a preset printing link node set.

In one embodiment, the preset set of printing link nodes comprises: at least one of interface parameter input (API parameter input), interface parameter output (API parameter output), authentication parameter input, authentication parameter output, service parameter input, service parameter output and abnormity. The method comprises the steps of setting a preset printing link node set to comprise API input parameters, API output parameters, authentication input parameters, authentication output parameters, service input parameters, service output parameters and abnormity, so that the full link log of an interface request is printed at a gateway server, namely, the log data of a gateway side node can be printed, the log data of a business side can be printed, a calling party can inquire the full link log of the interface request at the gateway server, the convenience of log inquiry is improved, and the problem that one interface request needs the business side and the gateway server to print the log data respectively in the related technology is solved.

It should be noted that, in an embodiment, the service entry and service exit refer to services provided by a service provider. The exception refers to a node of which the task execution result requested by the interface is abnormal.

In one embodiment, a preset set of print link nodes for a print log is obtained upon initialization of the server. After the task of the interface request on the current link node is executed, the server judges whether the current link node belongs to the preset printing link node combination, and if the current link node belongs to the preset printing link node combination, the server prints the log data of the current link node based on the interface request parameter, the interface calling parameter and the request identifier.

In one example, a server obtains a preset set of print link nodes for a print log input by a business party or API gateway provider. In another example, the service side or the API gateway provider sets a preset printing link node set of the printing log on the gateway configuration domain, and the gateway runs the initialization of the domain, and reads the preset printing link node set of the printing log from the gateway configuration domain through the kbus/task. Further, in the event of an update of the preset print link node set of the print log, the kbus/task re-reads the updated preset print link node set of the print log from the gateway configuration domain.

In one embodiment, as shown in fig. 4, the gateway operating domain synchronizes data such as API configuration, parameter configuration, and custom log parameter configuration from the gateway management domain through kbus/task, and the service caller (e.g., ISV, internal user, and service caller) sends an interface request to the gateway operating domain, and after receiving the interface request, the gateway operating domain generates a request identifier and calls a pre-packaged log printing tool to print log data on link nodes belonging to a preset printing link node set.

In the above embodiment, the link nodes for printing the log data are screened by printing the log data on the link nodes belonging to the preset printing link node set requested by the interface, so that only the log data of the key link nodes are generated, and the reduction of the printing workload of the log data is facilitated.

In one embodiment, as shown in fig. 5, the log processing method includes:

s501: an API request is received.

In one embodiment, a gateway run domain receives an API request.

S502: and generating a request identification.

In one embodiment, the gateway runtime domain generates a globally unique request identifier upon receiving the API request.

S503: and judging whether the target parameter belongs to a preset printing parameter set.

In the case where the target parameter does not belong to the preset print parameter set, S504 is executed. In the case where the target parameter belongs to the preset print parameter set, S505 is executed.

S504: the interface request is processed normally until the end,

in one embodiment, if the target parameter does not belong to the preset white list, the log data of the interface request is not printed, and only the task requested by the interface is processed until the end.

S505: and judging whether the server is configured with the self-defined log parameters.

In one embodiment, in the case that the server configures the custom log parameter, S506 is executed. In case the server does not configure the custom log parameter, S507 is executed.

In one embodiment, it is determined whether the server is configured with custom log parameters by reading information stored in a local cache. And under the condition that the self-defined log parameters are stored in the local cache, confirming that the self-defined log parameters are configured by the server, or else, confirming that the self-defined log parameters are not configured by the server.

S506: the log printing tool prints the log data of the target link node requested by the interface based on the request identifier, the interface request parameter, the interface calling parameter and the custom log parameter.

The target link node is used for indicating the link nodes belonging to the preset printing link node set.

In one embodiment, when the server is configured with the custom log parameter, the content corresponding to the custom log parameter is obtained from the interface request, and the custom log parameter and the content corresponding to the custom log parameter are printed. In addition, the interface request parameter and its corresponding content, the interface call parameter and its corresponding content, and the request identifier are also printed.

S507: and the log printing tool prints the log data of the target link node requested by the interface based on the request identifier, the interface request parameter, the interface calling parameter and a default log parameter pre-configured by the log printing tool.

Wherein the target link node belongs to a preset printing link node set.

In one embodiment, when the server does not configure the custom log parameter, the content corresponding to the default log parameter, which is configured in advance by the log printing tool, such as an error code (result), an error description (errMsg), and the like, is obtained, and then the default log parameter and the content corresponding to the default log parameter, which are configured in advance by the log printing tool, are printed. In addition, the interface request parameter and its corresponding content, the interface call parameter and its corresponding content, and the request identifier are also printed.

Optionally, the log data includes a log index and log details, where the log index and the log details include the request identifier respectively. After S203, the log processing method further includes:

the method comprises the following steps: and storing the log index in a first database, wherein the time for storing the log index in the first database is a first preset time.

In one embodiment, the first database and the second database are installed on a server.

In one embodiment, the gateway run domain sends the log data to a kfaka message, and the log data is distributed to the log center for storage by consuming the kfaka message. Specifically, the log index is distributed to the log center and stored in the first database by consuming topic in the kfaka message.

In one embodiment, the main key of the first database is the gateway cluster + timestamp, thereby ensuring uniqueness of the log index. Specifically, the first database stores the log indexes in a fragmentation mode according to the gateway cluster and the timestamp, the indexes are built according to the days, only the log indexes with the first preset duration (for example, 7 days) are reserved, and the log indexes with the storage duration larger than the first preset duration are cleaned regularly to save storage resources.

In one embodiment, the first database is an ES database. Of course, the first database may also be other databases that facilitate retrieval of the index, and the present disclosure is not limited thereto.

Step two: and storing the log details in a second database, wherein the time length of the log details stored in the second database is a first preset time length.

In one embodiment, the gateway run domain sends the log data to a kfaka message and then distributes the log data to a log center for storage by consuming the kfaka message. Specifically, by consuming the klog in the kfaka message, the log details are distributed to the log center and stored in the second database.

In one embodiment, the log details are json data in the log data.

Optionally, the first database and the second database are different databases. By respectively storing the log indexes and the log details in different databases, the hierarchical storage of the log indexes and the log details is realized, and the storage resources are saved.

In an embodiment, the log index includes parameters such as an interface request parameter, a request identifier, and an interface call parameter, and the caller may perform log query based on the parameters in the log index, for example, send a first query request including a query statement to the server by using the parameters in the log index as the query statement, which is specifically referred to in the following embodiments and is not described herein again.

In one embodiment, the log details include a request identifier, a custom log parameter or a default log parameter, time consumption information of the interface request, and the like, and when the interface request fails, the caller may locate the reason of the failure based on the log details.

In one embodiment, in the case that the storage duration of the log index and the log detail in the first database and the second database is greater than or equal to a first preset duration, the first database and the second database delete the log index and the log detail, respectively.

In one embodiment, the first predetermined period of time is 7 days. That is, the log index in the first database and the log details in the second database are stored for only 7 days, and the log index and the log details in more than 7 days are cleaned up periodically. Most log query problems can be solved by setting the first preset time length to 7 days, and log data before 7 days can be queried in the third database through an offline hive table.

It should be noted that the first preset time period may also be other time periods, for example, 3 days, 10 days, or 6 days, etc., which is not limited by the present disclosure.

In one embodiment, the second database is an HBase database. Of course, the second database may be other databases that facilitate storing json data, and the disclosure is not limited in this regard.

In the above embodiment, the amount of occupied storage resources of each database is reduced by storing the log index and the log details in the first database and the second database, respectively. Further, by setting the duration of storing the log index in the first database and the duration of storing the log details in the second database to be both the first preset duration, the log index and the log details are respectively and temporarily stored in the first database and the second database, so that the requirement that a caller inquires recent log data can be met, and the storage resources of the first database and the second database can be greatly saved.

Optionally, the log processing method further includes: and storing the log data in a third database, wherein the time for storing the log data in the third database is a second preset time, and the second preset time is longer than the first preset time.

In some embodiments, the log data includes a log index and log details. The log index includes parameters such as an interface request parameter, a request identifier, and an interface call parameter, and the caller may perform log query based on the parameters in the log index, for example, send a first query request including a query statement to the server by using the parameters in the log index as the query statement, which is specifically referred to in the following embodiments and is not described herein again. The log details comprise a request identifier, a self-defined log parameter or a default log parameter, time-consuming information of the interface request and the like, and when the interface request fails, the calling party can locate the reason of the failure based on the log details.

In one embodiment, in order to implement long-term storage of log data in the third database to meet the requirement of the caller to query the historical log data, the second preset time period may be set to a longer time period, for example, half a year, or three years, and the like, which is not limited by the present disclosure.

In one embodiment, the third database is a Hive database.

In one embodiment, the third database is installed on the target server, and the third database is used for storing the log data of the interface request in the third database for a long time, so that the influence of the log data stored on the server on the processing of the interface request by the server is reduced.

In one embodiment, the log data requested by the interface is collected offline from a local cache of the gateway operational domain by a log collector and stored in a third database.

In one embodiment, the log data in the local cache of the gateway operation domain is deleted when the storage amount of the log data in the local cache of the gateway operation domain is greater than or equal to a preset storage amount. For example, the preset storage amount may be 200MB, 500MB, or 1GB, and of course, the preset storage amount may be other values, and the disclosure is not limited thereto.

In another embodiment, the log data in the local cache of the gateway operating domain is deleted when the storage duration of the log data in the local cache of the gateway operating domain is greater than or equal to a preset storage duration.

The method and the device have the advantages that under the condition that the preset condition is met, for example, the storage capacity is larger than or equal to the preset storage capacity, or the storage duration is larger than or equal to the preset storage duration, the log data in the local cache of the gateway operation domain are deleted, and therefore the occupied space of the log data in the local cache of the gateway operation domain is reduced.

Optionally, the third database and the first database are different databases, and the third database and the second database are different databases, so that three-level storage of the log data is realized, that is, the first-level storage is used for indicating the first database to temporarily store the log index, the second-level storage is used for indicating the log details temporarily stored in the second database, and the third-level storage is used for indicating the third database to store the log data for a long time.

In the embodiment, because the log data in the first database and the second database are temporarily stored, the log data requested by the interface is stored in the third database for a long time, which is beneficial to realizing the query of the historical log data, avoiding that the user can not query the historical log data requested by the interface, and improving the convenience of log query.

Optionally, the log processing method further includes: the method comprises the following steps: storing the log data in the case that the log type of the log data belongs to a known log type; step two: in the event that the log type of the log data does not belong to a known log type, the log data is discarded.

Wherein the known log types include: at least one of an interface in-parameter (API _ INPUT) type, an interface out-parameter (API _ OUTPUT) type, an authentication in-parameter (AUTH _ INPUT) type, an authentication out-parameter (AUTH _ OUTPUT) type, a SERVICE in-parameter (SERVICE _ INPUT) type, a SERVICE out-parameter (SERVICE _ OUTPUT) type, and an EXCEPTION (EXCEPTION) type.

In one embodiment, after receiving the log data, determining whether the log type in the log index belongs to a known log type, and in the case of belonging to the known log type, performing an operation of storing the log data, specifically, storing in the first database if the log index is received, and storing in the second database if the log index is received. In the case of not being of a known log type, it is discarded.

In the embodiment, the log data is stored when the log data belongs to the known log type, and the log data is discarded when the log data does not belong to the known log type, so that the screening of the link node logs requested by the interface is facilitated, useless log data of the link nodes are filtered, only the log data of the link nodes with analysis values are stored, and the storage resource occupancy rate is reduced.

Optionally, storing the log details in a second database comprises: the method comprises the following steps: in the case that the request identification is not included in the second database, inserting the log details into the second database; step two: and in the case that the request identification is included in the second database, additionally storing the log details in the row of the second database where the request identification is located.

In an embodiment, when storing the log details, first, it is queried whether a request identifier corresponding to the log details is stored in the second data, and if the request identifier is stored in the second database, the row where the request identifier is located is added to the log details, that is, the log details and the request identifier are in the same row, and if the request identifier is not stored in the second database, the log details are inserted into the second database. It should be noted that, in the second database, all log data corresponding to one request identifier are in one row, that is, the log data of each link node requested by one interface are in the same row.

In the above embodiment, when the second database includes the request identifier, the log details are stored in the row of the second database where the request identifier is located, and when the second database does not include the request identifier, the log details are inserted into the second database, so that an interface request only records one log in the second database, and logs of different link nodes of the same interface request are appended to the same log, which is helpful for querying the log, and a full link log of the interface request can be searched in one query record based on the request identifier, thereby improving query speed and convenience.

In one embodiment, as shown in fig. 6, a log processing method includes:

s601: and consuming the log data.

In one embodiment, the log data is stored in a kfaka message and consumption of the log data is achieved by consuming the kfaka message.

S602: and judging whether the log data is a known log type.

In one embodiment, S603 is performed in the case that the log data is not of a known log type. In the case where the log data is of a known log type, S604 is executed.

S603: the log data is discarded.

S604: log data is stored asynchronously.

In one embodiment, log indexes and log details in the log data are stored asynchronously.

S605: and judging whether the index is a log index.

In the case of the log index, S606 is executed. In the case of not the log index, S607 is executed.

S606: the log index is stored in a first database.

S607: and judging whether the request identification exists in the second database.

In the case where the request identification exists in the second database, S608 is executed. In the case where the request identification does not exist in the second database, S609 is executed.

S608: the log details are appended to the row in the second database where the request identification is located.

S609: the log details are inserted into a second database.

In one embodiment, as shown in fig. 7, after receiving the log data sent by the kfaka message, the log center stores the log index in the first database and the log details in the second database. In addition, the log center acquires the log data requested by the interface from the gateway operation domain and stores the log data in a third database. In addition, the caller (ISV), the internal user or the service side can perform log query through the log center.

Optionally, as shown in fig. 8, the log processing method further includes:

s801, receiving a first query request sent by a caller, wherein the first query request comprises a query statement.

Wherein the query statement includes at least one of a request identification, an interface request parameter, or an interface call parameter.

It should be noted that the query statement is used to indicate a query condition of the first query request, that is, the first query request is used to request to query log data matched with the query statement.

In one embodiment, as shown in FIG. 9, a caller (ISV) enters a query statement through a logging tool (i.e., a logging query platform) provided by a development portal and sends a first query request. By providing the log query platform, the visual query of a calling party is realized, and the log query speed is improved.

In another embodiment, as shown in fig. 9, the internal user inputs a query statement through a log management tool provided by the gateway management domain and sends a first query request. By providing the log management tool, the visual query of an internal user is realized, and the log query speed is improved.

S802, inquiring a target log index corresponding to the query statement from the first database, and returning the target log index to the caller.

It should be noted that each log index corresponds to a unique request identifier. The target log index is a log index that matches the query statement among the plurality of log indexes stored in the first database.

In one embodiment, after receiving the first query request, the log center queries a target log index matching the query statement from a plurality of log indexes in the first database, and sends the target log index to a caller, for example, an ISV, and after receiving the target log index, the caller displays the target log index on a log query interface. And when the inquirer triggers a certain target log index, the caller sends a second inquiry request for inquiring the log details corresponding to the triggered target log index.

S803, receiving a second query request sent by the caller, wherein the second query request comprises a target request identifier of the interface request to which the target log index belongs.

In one embodiment, after receiving the second query request, the log center queries the log details from the second database according to the target request identifier.

S804: and inquiring the target log details corresponding to the target request identification from the second database, and returning the target log details to the caller based on the second inquiry request.

In one embodiment, after receiving the second query request, the log center queries target log details corresponding to the target request identifier from the second database, and sends the target log details to the sending caller, and after receiving the target log details, the caller displays the target log details on the log query interface.

In the above embodiment, by performing hierarchical retrieval, that is, first querying a target log index corresponding to the query statement from the first database, and then querying the target log details from the second database based on the target request identifier requested by the interface to which the target log index belongs, since the data size of the log index is relatively small, first querying the matched log index based on the query statement, and determining the log details based on the request identifier in the log index, the log query efficiency is improved, for example, the log query time is reduced from an hour level to a minute level.

The scheme provided by the embodiment of the application is mainly introduced from the perspective of a method. To implement the above functions, it includes hardware structures and/or software modules for performing the respective functions. Those of skill in the art would readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The embodiment of the disclosure also provides a log processing device.

Fig. 10 is a block diagram illustrating a log processing apparatus according to an example embodiment. Referring to fig. 10, the log data processing apparatus 1000 includes a receiving module 1001, a calling module 1002, and a log module 1003.

A receiving module 1001 configured to execute receiving an interface request and generate a request identifier of the interface request; the interface request comprises interface request parameters, and the interface request parameters are used for representing caller information of the interface request and interface information requested by the interface request. For example, in conjunction with fig. 2, the generating module 1001 may be configured to perform S201.

A calling module 1002 configured to execute calling a pre-packaged log printing tool, where the log printing tool is used to instruct printing of log data using a request identifier, an interface request parameter, and an interface calling parameter; the interface call parameters are used to characterize the parameters used in executing the interface request. For example, in conjunction with fig. 2, the calling module 1002 may be configured to perform S202.

A log module 1003 configured to execute printing of log data requested by the interface based on the log printing tool. For example, in conjunction with fig. 2, the log module 1003 may be used to perform S203.

In one possible embodiment, the log module 1003 is configured to perform: calling a pre-packaged log printing tool under the condition that the target parameter belongs to a preset printing parameter set; the target parameters include interface request parameters and/or interface call parameters.

In another possible embodiment, the log module 1003 is configured to perform: under the condition that the server is determined to be configured with the self-defined log parameters, the log printing tool prints the log data requested by the interface based on the request identifier, the interface request parameters, the interface calling parameters and the self-defined log parameters; and under the condition that the server is determined not to be configured with the self-defined log parameters, the log printing tool prints the log data requested by the interface based on the request identifier, the interface request parameters, the interface calling parameters and default log parameters pre-configured by the log printing tool.

In another possible embodiment, the log module 1003 is configured to perform: acquiring a current link node for executing an interface request; and under the condition that the current link node belongs to the preset printing link node set, the log printing tool prints the log data of the current link node requested by the interface based on the request identifier, the interface request parameter and the interface calling parameter.

In another possible implementation, the apparatus further includes a sending module 1004 configured to perform: after the log data requested by the interface is printed based on the log printing tool, request result information of the interface request is returned to the caller, and the request result information comprises a request identifier and an interface calling parameter.

In another possible embodiment, the log data includes a log index and log details, and the apparatus further includes a storage module 1005 configured to perform: storing the log index in a first database; the time length of the first database for storing the log index is a first preset time length; storing the log details to a second database; the time length of the second database for storing the log details is a first preset time length.

In another possible implementation, the storage module 1005 is further configured to perform: and storing the log data in a third database, wherein the time for storing the log data in the third database is a second preset time, and the second preset time is longer than the first preset time.

In another possible implementation, the storage module 1005 is further configured to perform: in the case that the request identification is not included in the second database, inserting the log details into the second database; and under the condition that the request identification is included in the second database, storing the log details into a row of the second database where the request identification is located.

In another possible implementation, the apparatus further includes a query module 1006 configured to perform: receiving a first query request sent by a calling party, wherein the first query request comprises a query statement; the query statement comprises at least one of a request identifier, an interface request parameter and an interface calling parameter; inquiring a target log index corresponding to the query statement from the first database, and returning the target log index to the caller based on the first query request; receiving a second query request sent by a calling party, wherein the second query request comprises a target request identifier of an interface request to which a target log index belongs; and inquiring the target log details corresponding to the target request identification from the second database, and returning the target log details to the caller based on the second inquiry request.

With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

Fig. 11 is a block diagram illustrating a server 1100 according to an example embodiment, where the server 1100 may vary greatly in configuration or performance, and may include one or more processors 1101 and one or more memories 1102. At least one instruction is stored in the memory 1102, and the at least one instruction is loaded and executed by the processor 1101 to implement the log processing method provided by each method embodiment described above. Of course, the server 1100 may also include other components for implementing the functions of the device, which are not described herein.

In an exemplary embodiment, the disclosed embodiments also provide a computer-readable storage medium comprising instructions, such as the memory 1102 comprising instructions, executable by the processor 1101 of the server 1100 to perform the log processing method described above.

In actual implementation, the processing functions of the receiving module 1001, the calling module 1002, the logging module 1003, the sending module 1004, the storing module 1005 and the querying module 1006 may be implemented by the processor 1101 shown in fig. 11 calling the program code in the memory 1102. The specific execution process may refer to the description of the log processing method, and is not described herein again.

Alternatively, the computer-readable storage medium may be a non-transitory computer-readable storage medium, which may be, for example, a Read-Only Memory (ROM), a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.

In an exemplary embodiment, the disclosed embodiments also provide a computer program product comprising one or more instructions executable by the processor 1101 of the server 1100 to perform the log processing method described above.

It should be noted that the instructions in the computer-readable storage medium or one or more instructions in the computer program product are executed by the processor 1101 of the server 1100 to implement the processes of the embodiment of the log processing method, and the same technical effects of the log processing method can be achieved, and are not described herein again to avoid repetition.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A log processing method, for a server, the method comprising:

receiving an interface request, and generating a request identifier of the interface request, wherein the interface request comprises interface request parameters, and the interface request parameters are used for representing caller information of the interface request and interface information requested by the interface request;

calling a pre-packaged log printing tool, wherein the log printing tool is used for indicating that log data are printed by using the request identifier, the interface request parameters and the interface calling parameters; the interface calling parameter is used for representing a parameter used when the interface request is executed;

and printing the log data requested by the interface based on the log printing tool.

2. The method of claim 1, wherein invoking the pre-packaged journal printing tool comprises:

calling the pre-packaged log printing tool under the condition that the target parameter belongs to a preset printing parameter set; the target parameters comprise the interface request parameters and/or the interface calling parameters.

3. The method of claim 1, wherein printing the log data requested by the interface based on the log printing tool comprises:

under the condition that the server is determined to be configured with a self-defined log parameter, the log printing tool prints the log data of the interface request based on the request identifier, the interface request parameter, the interface calling parameter and the self-defined log parameter;

and under the condition that the server is determined not to be configured with the self-defined log parameters, the log printing tool prints the log data requested by the interface based on the request identifier, the interface request parameters, the interface calling parameters and default log parameters pre-configured by the log printing tool.

4. The method of claim 1, wherein printing the log data requested by the interface based on the log printing tool comprises:

acquiring a current link node executing the interface request;

and under the condition that the current link node belongs to a preset printing link node set, the log printing tool prints the log data of the current link node requested by the interface based on the request identifier, the interface request parameter and the interface calling parameter.

5. The method of claim 1, wherein after printing log data requested by the interface based on the log printing tool, the method further comprises:

and returning request result information of the interface request to the caller, wherein the request result information comprises the request identifier and the interface calling parameter.

6. The method of claim 1, wherein the log data comprises log indexes and log details, and wherein after the log data requested by the interface is printed based on the log printing tool, the method further comprises:

storing the log index in a first database; the time length of the first database for storing the log index is a first preset time length;

storing the log details in a second database; the time length of the second database for storing the log details is the first preset time length.

7. A log processing apparatus, comprising:

the receiving module is configured to execute receiving of an interface request and generate a request identifier of the interface request; the interface request comprises an interface request parameter; the interface request parameter is used for representing caller information of the interface request and interface information requested by the interface request;

a calling module configured to execute calling a pre-packaged log printing tool, the log printing tool being used to instruct to print log data using the request identifier, the interface request parameter and an interface calling parameter; the interface calling parameter is used for representing a parameter used when the interface request is executed;

a log module configured to perform printing of log data requested by the interface based on the log printing tool.

8. A server, comprising:

a processor;

a memory for storing the processor-executable instructions;

wherein the processor is configured to execute the instructions to implement the method of any one of claims 1 to 6.

9. A computer-readable storage medium, wherein instructions in the computer-readable storage medium, when executed by a processor of a server, enable the server to perform the method of any of claims 1 to 6.

10. A computer program product, characterized in that it comprises computer instructions which, when run on a server, cause the server to carry out the method according to any one of claims 1 to 6.