An ELK-based log storage method
By dividing ELK logs into three categories—call chains, exceptions, and important logs—and recording and sharing key information respectively, the problems of large log volume and low efficiency in exception log search are solved, achieving efficient log storage and querying.
Patent Information
- Application Number
- CN202310400371.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-04-14
- Publication Date
- 2026-02-17
- Estimated Expiration
- 2043-04-14
AI Technical Summary
In existing technologies, the method of recording call chain logs results in an excessive amount of logs, which requires regular cleanup. It is impossible to store important logs for a long time, and the mixed storage of exception logs and call chain logs leads to low efficiency in exception log search and loss of exception logs in try-catch blocks.
Logs are divided into three types: call chain logs, exception logs, and important logs. Each type is managed by a different logger, while sharing requestId, sessionId, user ID, and username. The loggers are set at different interception layers to ensure that exception logs are recorded and stored separately.
It increases log storage capacity, facilitates querying during abnormal events, ensures long-term preservation of important logs, and allows for quick location of abnormal logs via requestId, thus solving the problems of large log volume and low search efficiency.
Smart Images
Figure CN116737679B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and in particular to an ELK-based log storage method. Background Technology
[0002] ELK is an abbreviation for three open-source software programs: Elasticsearch, Logstash, and Kibana. Elasticsearch is an open-source distributed search engine that provides three main functions: data collection, analysis, and storage. Its features include: distributed architecture, zero-configuration, automatic discovery, automatic index sharding, index replication, RESTful API, multiple data sources, and automatic search load balancing. Logstash is primarily used for collecting, analyzing, and filtering logs. It supports numerous data acquisition methods and typically operates in a client / server architecture. The client is installed on the host where logs are collected, while the server filters, modifies, and sends the received logs from various nodes to Elasticsearch. Kibana is also an open-source and free tool. It provides a user-friendly web interface for log analysis provided by Logstash and Elasticsearch, helping to aggregate, analyze, and search important log data. Many companies in the industry use ELK as their logging system.
[0003] Currently, most solutions used in the industry involve outputting all logs from the call chain to a single log index in Elasticsearch (an index in Elasticsearch is equivalent to a table in a database), such as... Figure 1 As shown.
[0004] When a user visits a web site, the following will occur: Figure 2 The call chain is: web -> service A -> service C -> database, or web -> service A -> service B -> database. Existing solutions typically generate a requestId (request identifier) at the entry point of the call, and the call proceeds through methods or services (…). Figure 2 The service will have a log probe that records the current method name, input parameters, output parameters, call time, and requestId in the ELK system.
[0005] However, this method has the following problems:
[0006] Recording call chains generates a large amount of logs (especially in large systems), resulting in a limited amount of logs that can be stored and requiring periodic cleanup. In typical systems, only three to six months of logs are retained. However, some critical enterprises wish to retain logs permanently.
[0007] This recording method, when an exception occurs in the call chain, stores both the exception log and the call chain log under the same index, thus hindering the search of the exception log. Figure 1 As can be seen, when there are exception logs, it's not immediately clear from the current view where the exception occurred. Furthermore, because the cascading log is massive, searching for exception logs within it is quite slow. Additionally, in Java programs, sometimes we don't want to throw exceptions but instead use try-catch (to catch exceptions), such as... Figure 3 Although there is an exception here, the business does not want to throw it, so the exception log will be lost. Summary of the Invention
[0008] To overcome the shortcomings of existing technologies, this invention provides an ELK-based log storage method to solve the aforementioned problems.
[0009] The technical solution adopted by this invention to solve its technical problem is: an ELK-based log storage method, comprising:
[0010] S1: Establish a call chain logger, an exception logger, and an important logger;
[0011] S2: Obtain chain logs by calling the chain logger, obtain exception logs by calling the exception logger, and obtain important logs by calling the important logger;
[0012] S3: Enable the call chain logger, exception logger, and important logger to share requestId, sessionId, user ID, username, and entry method name.
[0013] It is worth noting that in step S1, the method info(String method, Date statTime, Object result, Object args) is set in the call chain logger, where the parameter String method is a string method, the parameter Date statTime is the method start time, the parameter Object result is the object result, and the parameter Object args is the return result.
[0014] The method info(String method, Date statTime, Object result, Object args) retrieves requestId, sessionId, user ID, and username from the traversal log context and records requestId, sessionId, user ID, and username along with the parameters String method, Date statTime, Object result, and Object args into the traversal log.
[0015] After establishing the call chain logger, set it in the web entry log layer, web exception interception layer, Dubbo call interception layer, MyBatis interception layer, and Dubbo service front-end interception layer, and set it to be invisible to programmers.
[0016] Optionally, in step S1, the exception logger is set with a method error(Throwable e) or a method error(String message, Throwable e), where the parameter Throwable e is an exception object e that can be thrown, and the parameter String message is an exception description.
[0017] The error(Throwable e) or error(String message, Throwable e) method retrieves the requestId, sessionId, user ID, username, and entry method from the exception log context, and records the requestId, sessionId, user ID, username, and entry method together with the parameter Throwable e and / or the parameter String message in the exception log.
[0018] After establishing the exception logger, set the exception logger in the web exception interception layer, the Dubbo call interception layer, the MyBatis interception layer, and the Dubbo service front-end interception layer, and set it to be callable by programmers.
[0019] Specifically, in step S1, the important log recorder is set to the method log(String funName, String message), where the parameter String funName is the function name and the parameter String message is the function information;
[0020] The method log(String funName, String message) retrieves the requestId, sessionId, user ID, username, and entry method from the context of important logs, and records the requestId, sessionId, user ID, username, and entry method together with the parameters String funName and String message in the important log.
[0021] After establishing an important logger, set it to be callable by the programmer.
[0022] Preferably, in step S1, when a request enters the web entry log layer, the method, method start time and parameters of the entry method are recorded first. When the request returns, the result is recorded, and then the call chain logger is used to output the link log.
[0023] Optionally, in step S1, when a request enters the entry method and an exception is thrown inside the entry method, it will be intercepted by the web exception interception layer. Then, the method, method start time and parameters are obtained from the web entry log layer. The exception information is used as the result, and the exception log is output using the call chain logger. Then, the error(Throwable e) method of the exception logger is used to output the detailed information of the exception. Finally, the 500 page specified by the user is returned.
[0024] It is worth noting that in step S1, the business method and the parameters to be transmitted are obtained from the interface method Result invoke(Invoker<?>invoker,Invocation invocation) corresponding to the org.apache.dubbo.rpc.Filter interface of the Dubbo interception layer, and the start time is recorded. Then, the requestId, sessionId, user ID, and username are obtained from the link log context, or the requestId, sessionId, user ID, username, and entry method are obtained from the exception log context. Finally, the Dubbo interception layer is invoked using RpcContext.getContext().setAttachment(String key,String... The `value` method records the `requestId`, `sessionId`, user ID, username, and entry method in the attachment of the sent packet, and then calls the `invoke` method of the `invoker` parameter to call the remote Dubbo service. When there is a return result, the call chain logger outputs the chain log. When the remote call throws an exception, the call chain logger first outputs the chain log, then the exception logger's `error(Throwable e)` method is called to output the exception details as the exception log, and then the exception is re-thrown.
[0025] Specifically, in step S1, the interface method Result invoke(Invoker<?>invoker,Invocation invocation) corresponding to the org.apache.dubbo.rpc.Filter interface of the Dubbo service pre-interception layer is used to first extract the requestId, sessionId, user ID, username, and entry method from the attachment of the sent packet, and then store them in the link log context and / or exception log context. The business method and the parameters to be transmitted corresponding to the business method are extracted from the parameters invoker and invocation, and the start time is recorded. Then, the invoke method of the parameter invoker is called to invoke the business implementation. When there is a return result, the link log is output using the call chain logger. When the business call throws an exception, the link log is first output using the call chain logger, and then the error(Throwable e) method of the exception logger is called to output the detailed information of the exception as the exception log, and the exception is re-thrown. Finally, the link log context and / or exception log context are cleared.
[0026] Preferably, in step S1, the interface method `Object intercept(Invocation invocation)` corresponding to the `org.apache.ibatis.plugin.Interceptor` interface of the MyBatis interceptor layer is used to obtain the database query statement to be executed from the `invocation` parameter as the method. Parameters are also retrieved from the `invocation` parameter, and the start time is recorded. Then, the `proceed` method of the `invocation` parameter is called to invoke the database. When a result is returned, the call chain logger outputs the chain log. When the database query statement execution throws an exception, the call chain logger first outputs the chain log, then the exception logger's `error(Throwable e)` method is called to output detailed exception information as an exception log, and the exception is then re-thrown.
[0027] Optionally, step S4 is also included, which includes: when it is necessary to call the internal web interface using HTTP, before initiating the HTTP call, obtaining the requestId from the link log context, the exception log context and / or the important log context, and filling the value of the requestId into the request header _requestId_.
[0028] The beneficial effects of this invention are as follows: In the ELK-based log storage method, the call chain log, exception log, and important log are separated, which facilitates the query of exception times and allows important logs to be stored for a longer period. Storing the call chain log, exception log, and important log in three different loggers increases the amount of log storage. Recording the call chain log, exception log, and important log under different indexes while sharing the requestId allows one to use the requestId under one index to query relevant information under another. The provided exception logger also records exceptions within try-catch blocks. Furthermore, in addition to sharing the requestId (request identifier), the call chain log, exception log, and important log also share the sessionId (session identifier), user ID, username, and entry method name (the entry method name is particularly important in important logs because a log entry may be outdated and cannot be found by calling the call chain log using the requestId). Thus, when an exception occurs in the call chain, the exception log can still be searched using the requestId under one index. Attached Figure Description
[0029] Figure 1 For existing Elasticsearch indexes;
[0030] Figure 2 This is a schematic diagram illustrating the process of a user accessing a web application in the existing technology.
[0031] Figure 3 This is a Java program in the existing technology center that has an exception but is not intended to throw an exception.
[0032] Figure 4 This is a flowchart of an ELK-based log storage method in one embodiment of the present invention;
[0033] Figure 5 This is a configuration diagram of three loggers and six interception layers in one embodiment of the present invention;
[0034] Figure 6 This is a user-specified page 500 in one embodiment of the present invention. Detailed Implementation
[0035] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings. It should be noted that these descriptions are for the purpose of aiding understanding the present invention, but do not constitute a limitation thereof. Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.
[0036] This invention is applicable to the SpringMVC+Dubbo microservice framework, providing an interception layer for SpringMVC and Dubbo.
[0037] like Figure 1-6 As shown, an ELK-based log storage method includes:
[0038] S1: Establish a call chain logger, an exception logger, and an important logger;
[0039] S2: Obtain chain logs by calling the chain logger, obtain exception logs by calling the exception logger, and obtain important logs by calling the important logger; also record exceptions in the try-catch block using the exception logger.
[0040] S3: Enable the call chain logger, exception logger, and important logger to share requestId, sessionId, user ID, username, and entry method name.
[0041] In the ELK-based log storage method, call chain logs, exception logs, and important logs are separated, facilitating the querying of exception times and allowing important logs to be stored for longer periods. Storing call chain logs, exception logs, and important logs in three different loggers increases the amount of log storage. Recording call chain logs, exception logs, and important logs under different indexes while sharing the requestId allows one index's requestId to retrieve relevant information under another index. The provided exception logger also records exceptions within try-catch blocks. Furthermore, in addition to sharing the requestId (request identifier), call chain logs, exception logs, and important logs also share the sessionId (session identifier), user ID, username, and entry method name (the entry method name is particularly important in important logs because a log entry may be outdated and cannot be found by calling the call chain log using the requestId). Thus, when an exception occurs in the call chain, the exception log can still be found using the requestId under a single index.
[0042] It is worth noting that in step S1, the method info(String method, Date statTime, Object result, Object args) is set in the call chain logger, where the parameter String method is a string method, the parameter Date statTime is the method start time, the parameter Object result is the object result, and the parameter Object args is the return result.
[0043] The method info(String method, Date statTime, Object result, Object args) retrieves requestId, sessionId, user ID, and username from the traversal log context and records requestId, sessionId, user ID, and username along with the parameters String method, Date statTime, Object result, and Object args into the traversal log.
[0044] After establishing the call chain logger, set it up in the web entry log layer, web exception interception layer, Dubbo call interception layer, MyBatis interception layer, and Dubbo service pre-interception layer, and make it invisible to programmers. The call chain logs recorded by the call chain logger will be output to the ELK's userlog-* index.
[0045] Optionally, in step S1, the exception logger is set with a method error(Throwable e) or a method error(String message, Throwable e), where the parameter Throwable e is a throwable exception object e, used to set the exception object e as throwable, and the parameter String message is an exception description, used to set the exception description for the exception object.
[0046] The error(Throwable e) or error(String message, Throwable e) method retrieves the requestId, sessionId, user ID, username, and entry method from the exception log context, and records the requestId, sessionId, user ID, username, and entry method together with the parameter Throwable e and / or the parameter String message in the exception log.
[0047] After establishing the exception logger, set it in the web exception interception layer, Dubbo call interception layer, MyBatis interception layer, and Dubbo service pre-interception layer, and configure it to be callable by programmers. Exception logs recorded by the exception logger will be output to the ELK's exceptionLog-* index.
[0048] Preferably, in step S1, the important log recorder is set to a method log(String funName, String message), where the parameter String funName is the function name and the parameter String message is the function information;
[0049] The method log(String funName, String message) retrieves the requestId, sessionId, user ID, username, and entry method from the context of important logs, and records the requestId, sessionId, user ID, username, and entry method along with the parameters String funName and String message into the important log.
[0050] After establishing the critical logger, set it to a callable state by the programmer. Important logs recorded by the critical logger will be output to the ELK's normalOperationLog-* index.
[0051] Specifically, in step S1, when a request enters the web entry log layer, the method, method start time and parameters of the entry method are recorded first. When the request returns, the result is recorded, and then the call chain logger is used to output the chain log.
[0052] It is worth noting that in step S1, when a request enters the entry method and an exception is thrown within the entry method, it will be intercepted by the web exception interception layer. Then, the method, method start time, and parameters are retrieved from the web entry log layer. The exception information is used as the result, and the exception log is output using the call chain logger. Then, the exception logger's `error(Throwable e)` method outputs detailed exception information, and finally, a 500 page is returned to the user. The `requestId` value can be displayed at a specific location on the 500 page, such as... Figure 6 As shown, a web exception interception layer is set up in the web project. Users can set error pages in this layer. When an exception is thrown, the requestId is exposed, which makes it easy to quickly locate the source of the exception.
[0053] Preferably, in step S1, the business method and the parameters to be transmitted corresponding to the business method are obtained from the interface method Result invoke(Invoker<?>invoker,Invocation invocation) corresponding to the org.apache.dubbo.rpc.Filter interface of the Dubbo interception layer, and the start time is recorded. Then, the requestId, sessionId, user ID, and username are obtained from the link log context, or the requestId, sessionId, user ID, username, and entry method are obtained from the exception log context. Finally, the Dubbo interception layer is invoked using RpcContext.getContext().setAttachment(String key,String... The `value` method records the `requestId`, `sessionId`, user ID, username, and entry method in the attachment of the sent packet. Then, it calls the `invoke` method of the `invoker` parameter to call the remote Dubbo service. When there is a return result, the call chain logger outputs the chain log. When the remote call throws an exception, the call chain logger first outputs the chain log, which at this time contains simple information about the exception as the result. Then, the `error(Throwable)` method of the exception logger is called to output the detailed information of the exception as the exception log, and the exception is re-thrown.
[0054] Optionally, in step S1, the interface method Result invoke(Invoker<?>invoker,Invocation invocation) corresponding to the org.apache.dubbo.rpc.Filter interface of the Dubbo service pre-interception layer is used to first extract the requestId, sessionId, user ID, username, and entry method from the attachment of the sent packet, and then store them in the link log context and / or exception log context. The business method and the parameters to be transmitted corresponding to the business method are extracted from the parameters invoker and invocation, and the start time is recorded. Then, the invoke method of the parameter invoker is called to invoke the business implementation. When there is a return result, the link log is output using the call chain logger. When the business call throws an exception, the link log is first output using the call chain logger. At this time, the link log is a simple information of the exception as the result. Then, the error(Throwable e) method of the exception logger is called to output the detailed information of the exception as the exception log, and the exception is re-thrown. Finally, the link log context and / or exception log context are cleared.
[0055] It is worth noting that in step S1, the interface method `Object intercept(Invocation invocation)` corresponding to the `org.apache.ibatis.plugin.Interceptor` interface of the MyBatis interceptor layer is used to obtain the database query statement to be executed from the `invocation` parameter as the method. The parameters are also retrieved from the `invocation` parameter, and the start time is recorded. Then, the `proceed` method of the `invocation` parameter is called to invoke the database. When a result is returned, the call chain logger outputs the chain log. When the database query statement execution throws an exception, the call chain logger first outputs the chain log, which at this time contains simple exception information as the result. Then, the `error(Throwable e)` method of the exception logger is called to output detailed exception information as the exception log, and the exception is then re-thrown.
[0056] The ELK-based log storage method also utilizes a basic information retrieval layer. It first attempts to retrieve the value of the "_requestId" header from the HttpServletRequest object's request header. If obtained, it is used as the requestId. If not, it attempts to retrieve the "_requestId" value from the request's URL parameters. If obtained, it is used as the requestId. If still not obtained, a requestId is generated for the current request. Then, it retrieves the sessionId, session information, user ID, and username from the HttpServletRequest object. Finally, it stores the requestId, sessionId, user ID, and username in the cascading log context, exception log context, or important log context. The session information is directly used by the web entry log layer. When request processing returns to the basic information retrieval layer, the log context is cleared.
[0057] like Figure 5 As shown, there are six interception layers. These six interception layers only require configuration and do not require programmers to write code. Their positions are as follows: Figure 5 As shown in the image. The MyBatis interception layer and Dubbo call interception layer are optional configurations and should only be configured when needed for the project.
[0058] It is worth noting that for internal HTTP calls, the call chain will be broken, meaning the requestId will be lost when the HTTP request is made. Therefore, in this embodiment, the ELK-based log storage method further includes step S4, which includes: when an internal web interface needs to be called via HTTP, before initiating the HTTP call, obtaining the requestId from the link log context, exception log context, and / or important log context, and filling the value of the requestId into the request header _requestId_. This way, when the web interface receives the request, it will obtain this requestId at the basic information acquisition layer, and the call chain will not be broken during internal HTTP calls.
[0059] The cascading log context, exception log context, and / or critical log context internally maintain a JDK-provided ThreadLocal object, which can store variables in the currently executing thread. The variables stored in the cascading log context, exception log context, and / or critical log context are a Map object for accessing common information needed for logging.
[0060] Because the three types of logs (link logs, exception logs, and important logs) are stored in three separate indexes, Elasticsearch allows you to configure storage strategies based on the index. This allows you to set a shorter expiration time for the userlog-* index and a longer time for the normalOperationLog-* index, thus balancing the need for both storage and long-term retention of important logs.
[0061] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings, but the present invention is not limited to the described embodiments. For those skilled in the art, various changes, modifications, substitutions, and variations can be made to these embodiments without departing from the principles and spirit of the present invention, and these variations still fall within the protection scope of the present invention.
Claims
1. An ELK-based log storage method, characterized in that, include: S1: Establish a call chain logger, an exception logger, and an important logger; The setup process includes: The method info(String method, Date statTime, Object result, Object args) is used to set the call chain logger. The parameter String method is the string method, the parameter Date statTime is the method start time, the parameter Object result is the object result, and the parameter Object args is the return result. The method info(String method, Date statTime, Object result, Object args) retrieves requestId, sessionId, user ID, and username from the traversal log context and records requestId, sessionId, user ID, and username along with the parameters String method, Date statTime, Object result, and Object args into the traversal log. After establishing the call chain logger, set the call chain logger in the web entry log layer, web exception interception layer, Dubbo call interception layer, MyBatis interception layer, and Dubbo service front interception layer, and set it to be invisible to programmers. The exception logger is set to either the method error(Throwable e) or the method error(String message, Throwable e), where the parameter Throwable e is the exception object e that can be thrown, and the parameter String message is the exception description; The error(Throwable e) or error(String message, Throwable e) method retrieves the requestId, sessionId, user ID, username, and entry method from the exception log context, and records the requestId, sessionId, user ID, username, and entry method together with the parameter Throwable e and / or the parameter String message in the exception log. After establishing the exception logger, set the exception logger in the web exception interception layer, the Dubbo call interception layer, the MyBatis interception layer, and the Dubbo service front interception layer, and set it to be callable by programmers. The important log recorder is set in the method log(String funName, String message), where the parameter String funName is the function name and the parameter String message is the function information; The method log(String funName, String message) retrieves the requestId, sessionId, user ID, username, and entry method from the context of important logs, and records the requestId, sessionId, user ID, username, and entry method along with the parameters String funName and String message into the important log. After establishing the important logger, set it to a state that can be called by the programmer; S2: Obtain chain logs by calling the chain logger, obtain exception logs by calling the exception logger, and obtain important logs by calling the important logger; S3: Enable the call chain logger, exception logger, and important logger to share requestId, sessionId, user ID, username, and entry method name.
2. The ELK-based log storage method of claim 1, wherein: In step S1, when a request enters the web entry log layer, the method, method start time and parameters of the entry method are recorded first. When the request returns, the result is recorded, and then the call chain logger is used to output the chain log.
3. The ELK-based log storage method of claim 2, wherein: In step S1, when a request enters the entry method and an exception is thrown inside the entry method, it will be intercepted by the web exception interception layer. Then, the method, method start time and parameters are obtained from the web entry log layer. The exception information is used as the result, and the exception log is output using the call chain logger. Then, the error(Throwable e) method of the exception logger is used to output the detailed information of the exception. Finally, the 500 page specified by the user is returned.
4. The ELK-based log storage method of claim 3, wherein: In step S1, the business method and its corresponding parameters to be transmitted are obtained from the interface method Result invoke(Invoker<?>invoker,Invocation invocation) of the org.apache.dubbo.rpc.Filter interface corresponding to the Dubbo call interception layer. The start time is recorded. Then, the requestId, sessionId, user ID, and username are obtained from the link log context, or from the exception log context. The requestId, sessionId, user ID, username, and entry method are obtained from the exception log context. The RpcContext.getContext().setAttachment(String key,String value) method provided by the Dubbo framework corresponding to the Dubbo call interception layer is called to record the requestId, sessionId, user ID, username, and entry method in the attachment of the sending packet. Then, the invoke method of the parameter invoker is called to call the remote Dubbo service. When there is a return result, the link log is output using the call chain log recorder. When a remote call throws an exception, the call chain logger first outputs the chain log, then the exception logger's error(Throwable e) method is called to output the exception details as the exception log, and then the exception is re-thrown.
5. The ELK-based log storage method of claim 4, wherein: In step S1, the interface method Resultinvoke(Invoker<?>invoker,Invocation invocation) corresponding to the org.apache.dubbo.rpc.Filter interface of the Dubbo service pre-interception layer is used. First, the requestId, sessionId, user ID, username, and entry method are extracted from the attachment of the sent packet and stored in the link log context and / or exception log context. The business method and the parameters to be transmitted for the business method are extracted from the parameters invoker and invocation, and the start time is recorded. Then, the invoke method of the parameter invoker is called to invoke the business implementation. When there is a return result, the link log is output using the call chain logger. When the business call throws an exception, the link log is output using the call chain logger first, and then the error(Throwable e) method of the exception logger is called to output the detailed information of the exception as the exception log and continue to throw the exception. Finally, the link log context and / or exception log context are cleared.
6. The ELK-based log storage method of claim 5, wherein: In step S1, the `Object intercept(Invocation invocation)` method corresponding to the `org.apache.ibatis.plugin.Interceptor` interface of the MyBatis interceptor layer is used to obtain the database query statement to be executed from the `invocation` parameter as the method. Parameters are also retrieved from the `invocation` parameter, and the start time is recorded. Then, the `proceed` method of the `invocation` parameter is called to invoke the database. When a result is returned, the call chain logger outputs the chain log. When the database query statement execution throws an exception, the call chain logger first outputs the chain log, then the `error(Throwable e)` method of the exception logger is called to output the detailed exception information as the exception log, and the exception is then re-thrown.
7. The ELK-based log storage method of claim 6, wherein: It also includes step S4, which includes: when it is necessary to call the internal web interface using HTTP, before initiating the HTTP call, first obtain the requestId from the link log context, the exception log context and / or the important log context, and fill the value of the requestId into the request header _requestId_.
Citation Information
Patent Citations
Log recording method and log system
CN101425034A
Computing device to detect malware
CN104205111A