Log tracking method and device, equipment and medium

Abstract

The embodiment of the invention provides a log tracking method and device, equipment and a medium, and relates to the technical field of computers. The method comprises the following steps: creating a user-defined thread pool, wherein the user-defined thread pool comprises sub-threads; when the user-defined thread pool needs to execute the asynchronous task, MDC information of the main thread is transmitted to the MDC of the sub-thread, so that log tracking is realized by tracking a unique identifier in the MDC information in a request link corresponding to the asynchronous task while the sub-thread executes the asynchronous task. Therefore, according to the log tracking method, the MDC information of the parent thread is transmitted to the child thread, it is ensured that the logs can keep a consistent context environment in the asynchronous task execution process, all the logs in the request link can be tracked according to the unique identifier (such as traceId) in the MDC information, and therefore the traceability of the logs is improved, and the user experience is improved. And the realization difficulty of subsequent problem tracking and performance analysis is reduced.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a log tracking method, device, equipment and medium. Background Art

[0002] Logging is an essential part of Java development. The purpose of logging is to clearly record each request so that subsequent problem tracking and performance analysis can be performed. Therefore, each request needs a unique identifier (traceId) to associate all logs in the entire request process.

[0003] In the related technology, the industry widely uses Java Simple Logging Facade forJava, slf4j) and the logging framework (logback) implement logging. Among them, slf4j acts on the abstraction of various logging frameworks, while logback specifically implements a logging framework of the slf4j logging interface. When using slf4j+logback for logging, developers can easily embed various context information in the log information, such as timestamp, log level, thread information, etc.

[0004] However, when asynchronous threads (such as threads in a thread pool) are executed, due to the independence between threads, these asynchronous threads will lose the traceId in the main thread, resulting in the transaction log being unable to form a complete link, which makes it difficult to track and analyze the problem. Summary of the invention

[0005] Based on the above problems, the present application provides a log tracking method, apparatus, device and medium, which can improve the traceability of the log and reduce the difficulty of subsequent problem tracking and performance analysis.

[0006] The embodiments of the present application disclose the following technical solutions:

[0007] In a first aspect, an embodiment of the present application discloses a log tracking method, the method comprising:

[0008] Creating a custom thread pool, wherein the custom thread pool includes child threads, and the child threads are used to execute asynchronous tasks;

[0009] When the custom thread pool needs to execute the asynchronous task, the mapping debugging context MDC information of the main thread is passed to the MDC of the child thread, so that while the child thread executes the asynchronous task, it realizes log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task.

[0010] Optionally, the custom thread pool includes multiple sub-threads, each of which is used to execute a different asynchronous task;

[0011] When the custom thread pool needs to execute the asynchronous task, the mapping debugging context MDC information of the main thread is passed to the MDC of the child thread, so that the child thread implements log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task while executing the asynchronous task, including:

[0012] When the custom thread pool needs to execute the asynchronous task, the MDC information of the main thread is passed to the MDC of the target child thread corresponding to the asynchronous task, so that the target child thread can realize log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task while executing the asynchronous task.

[0013] Optionally, after executing the step of transferring the mapping debugging context MDC information of the main thread to the MDC of the child thread, the method further includes:

[0014] When the child thread completes executing the asynchronous task, the MDC information in the child thread is cleared.

[0015] Optionally, creating a custom thread pool includes:

[0016] When a synchronous request is received and the synchronous request needs to call an asynchronous task, a custom thread pool is created after obtaining a unique identifier from a request header of the synchronous request and storing the unique identifier in the MDC of the main thread.

[0017] Optionally, the method further comprises:

[0018] When a synchronous request is received, and the synchronous request does not need to call an asynchronous task, a configuration file of the log framework is defined in the resource directory of the application, and the configuration file is used to configure the log output format and the log storage location;

[0019] By modifying the configuration file, a unique identifier is obtained from the request header of the synchronization request;

[0020] In response to the synchronization request, the log framework is used to output the log containing the unique identifier according to the log output format and log storage location indicated by the configuration file to achieve log tracking.

[0021] In a second aspect, an embodiment of the present application discloses a log tracking device, the device comprising: a creation module and a transmission module;

[0022] The creation module is used to create a custom thread pool, the custom thread pool includes child threads, and the child threads are used to execute asynchronous tasks;

[0023] The transfer module is used to transfer the mapping debugging context MDC information of the main thread to the MDC of the child thread when the custom thread pool needs to execute the asynchronous task, so that the child thread can realize log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task while executing the asynchronous task.

[0024] Optionally, the custom thread pool includes multiple sub-threads, each of which is used to execute a different asynchronous task;

[0025] The transmission module is specifically used to transmit the MDC information of the main thread to the MDC of the target child thread corresponding to the asynchronous task when the custom thread pool needs to execute the asynchronous task, so that the target child thread can realize log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task while executing the asynchronous task.

[0026] Optionally, the device further comprises: a clearing module;

[0027] The clearing module is used to clear the MDC information in the child thread after the child thread completes executing the asynchronous task.

[0028] Optionally, the creation module is specifically used to: when a synchronous request is received and the synchronous request needs to call an asynchronous task, after obtaining a unique identifier from a request header of the synchronous request and storing the unique identifier in the MDC of the main thread, create a custom thread pool.

[0029] Optionally, the device further comprises: a definition module, a modification module and an output module;

[0030] The definition module is used to define a configuration file of the log framework in the resource directory of the application when a synchronous request is received and the synchronous request does not need to call an asynchronous task, wherein the configuration file is used to configure the log output format and the log storage location;

[0031] The modification module is used to obtain a unique identifier from a request header of the synchronization request by modifying the configuration file;

[0032] The output module is used to respond to the synchronization request and use the log framework to output the log containing the unique identifier according to the log output format and log storage location indicated by the configuration file to achieve log tracking.

[0033] In a third aspect, the present application discloses a log tracking device, the device comprising: a memory and a processor;

[0034] The memory is used to store programs;

[0035] The processor is used to execute the program to implement the various steps of the log tracking method as described in the first aspect.

[0036] In a fourth aspect, the present application discloses a computer-readable medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the log tracking method described in the first aspect are implemented.

[0037] Compared with the prior art, this application has the following beneficial effects:

[0038] The embodiment of the present application provides a log tracking method, device, equipment and medium, the method comprising: creating a custom thread pool, the custom thread pool including child threads; when the custom thread pool needs to execute an asynchronous task, the mapping debugging context MDC information of the main thread is passed to the MDC of the child thread, so that the child thread can implement log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task while executing the asynchronous task. Thus, the log tracking method passes the MDC information of the parent thread to the child thread, ensuring that the log can maintain a consistent context environment during the execution of the asynchronous task, and can track each log in the request link according to the unique identifier (such as traceId) in the MDC information, thereby improving the traceability of the log and reducing the difficulty of subsequent problem tracking and performance analysis. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0040] Figure 1 A flow chart of a log tracking method provided in an embodiment of the present application;

[0041] Figure 2A A flowchart of another log tracking method provided in an embodiment of the present application;

[0042] Figure 2B A schematic diagram of an introduction framework provided in an embodiment of the present application;

[0043] Figure 2CA schematic diagram of a configuration file provided in an embodiment of the present application;

[0044] Figure 2D A first code schematic diagram provided for an embodiment of the present application;

[0045] Figure 2E A second code schematic diagram provided for an embodiment of the present application;

[0046] Figure 2F A third code schematic diagram provided for an embodiment of the present application;

[0047] Figure 2G A fourth code schematic diagram provided for an embodiment of the present application;

[0048] Figure 2H A schematic diagram of the core elements included in logback-spring.xml provided in an embodiment of the present application;

[0049] Fig.2I A fifth code schematic diagram provided for an embodiment of the present application;

[0050] Figure 2J A sixth code schematic diagram provided for an embodiment of the present application;

[0051] Figure 2K A seventh code schematic diagram provided for an embodiment of the present application;

[0052] Figure 3 A schematic diagram of a log tracking device provided in an embodiment of the present application;

[0053] Figure 4 A schematic diagram of a computer-readable medium provided for an embodiment of the present application. DETAILED DESCRIPTION

[0054] As described above, the asynchronous thread cannot directly inherit or obtain the traceId of the main thread during execution, which causes the log to be split between the asynchronous thread and the main thread. Specifically, when the main thread initiates an asynchronous request and records the traceId of the request in the log, the asynchronous thread cannot perceive this traceId, so the log generated during its execution cannot be associated with the log of the main thread through the traceId. This split state of logs not only increases the difficulty of problem tracking, but also reduces the overall effectiveness of the log system.

[0055] After research, the inventors proposed a log tracking method, device, equipment and medium. The log tracking method passes the MDC information of the parent thread to the child thread, ensuring that the log can maintain a consistent context environment during the execution of the asynchronous task, and can track each log in the request link according to the unique identifier (such as traceId) in the MDC information, thereby improving the traceability of the log and reducing the difficulty of subsequent problem tracking and performance analysis.

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

[0057] See also Figure 1 , which is a flow chart of a log tracking method provided by an embodiment of the present application. The method includes:

[0058] S101: Create a custom thread pool, where the custom thread pool includes child threads, and the child threads are used to execute asynchronous tasks.

[0059] A thread pool is a component that manages the life cycle of threads based on pooling technology. Using a thread pool can reduce the overhead of creating and destroying threads, and improve the responsiveness and efficiency of applications. A custom thread pool means that developers design and implement the specific logic of the thread pool according to their own needs, which may include the size of the thread pool, thread creation strategy, thread reuse mechanism, task queue management, etc. This customization method can make the thread pool more suitable for actual application scenarios and optimize performance and resource utilization.

[0060] The child thread is the basic unit of work in the custom thread pool. The child thread is obtained from the custom thread pool and is used to execute specific asynchronous tasks. It can be understood that the execution of the child thread is asynchronous, which means that the main thread can continue to execute other tasks without waiting for the child thread to complete, thereby improving the concurrent processing capability of the application.

[0061] Asynchronous tasks refer to tasks that can be executed without synchronization with the main thread. Asynchronous tasks may be tasks such as file reading and writing, network communication, and long-running calculations.

[0062] Specifically, when the main thread needs to hand over an asynchronous task to a child thread in a custom thread pool for asynchronous execution, the main thread creates a custom thread pool and submits the asynchronous task to the custom thread pool.

[0063] S102: When the custom thread pool needs to execute an asynchronous task, the mapping debug context MDC information of the main thread is passed to the MDC of the child thread, so that while the child thread executes the asynchronous task, it can implement log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task.

[0064] Mapped Diagnostic Context (MDC) is a mechanism provided by logging frameworks (such as Logback, log4j, etc.) to store and pass diagnostic context information related to the current thread in a multi-threaded environment. MDC information includes a unique identifier (i.e., traceId).

[0065] When the main thread needs to submit an asynchronous task to the custom thread pool for execution, it may have stored some MDC information in the main thread's MDC. In order to ensure that this MDC information is still available when the asynchronous task is executed, the main thread needs to pass this MDC information to the child thread.

[0066] When a child thread obtains an asynchronous task from a custom thread pool and executes it, it first receives and sets the MDC information related to the asynchronous task. In this way, during the execution of the asynchronous task, the logging framework can automatically include this MDC information in the log message. By tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task, the log can be tracked.

[0067] In some specific implementations, a custom thread pool may include multiple child threads, and each child thread is designed to execute different asynchronous tasks. This means that asynchronous tasks in the custom thread pool can be assigned to any available child thread for execution, and each child thread is independent when executing asynchronous tasks. Then, before assigning an asynchronous task to a child thread, the custom thread pool needs to determine which child thread is the target child thread, that is, which child thread will be responsible for executing the asynchronous task. This decision may be based on the current state of the child thread (such as whether it is idle), task priority, or other load balancing strategies. Once the target child thread is determined, the custom thread pool needs to pass the MDC information of the main thread to the MDC of the target child thread. In this way, when the target child thread starts to execute asynchronous tasks and generates logs, these logs will contain the correct MDC information, and the MDC information contains a unique identifier. The unique identifier allows developers to track and associate log messages throughout the request chain, making it easier to diagnose problems or analyze system behavior. Therefore, no matter how many child threads execute the asynchronous task separately and / or in relay, as long as they all pass and set the MDC information correctly, the generated log will contain this unique identifier, so that they can be easily associated to form a complete request tracking chain.

[0068] It should be noted that after the child thread in the custom thread pool completes its assigned asynchronous task, the MDC information in the child thread can be cleared. Because the MDC information is set for a specific asynchronous task, once the asynchronous task is completed, the MDC information should be cleared to avoid potential interference with subsequent asynchronous tasks or logging. In one example, the MDC.clear() method can be explicitly called in the asynchronous task code executed by the child thread to clear the MDC information. This is usually done after the task is executed, that is, in the finally part of the try-catch-finally block, to ensure that the MDC information can be cleared regardless of whether the task is successfully executed. This application does not limit the specific elimination method.

[0069] It is understandable that the main purpose of log tracing is to be able to trace and diagnose the execution path of an asynchronous request in a distributed system or complex multi-threaded application. By recording MDC information and maintaining consistency and continuity in the log, the efficiency and accuracy of troubleshooting can be greatly improved.

[0070] In summary, an embodiment of the present application provides a log tracking method, which passes the MDC information of the parent thread to the child thread, ensuring that the log can maintain a consistent context environment during the execution of the asynchronous task, and can track each log in the request link according to the unique identifier (such as traceId) in the MDC information, thereby improving the traceability of the log and reducing the difficulty of subsequent problem tracking and performance analysis.

[0071] See also Figure 2A , which is a flow chart of another log tracking method provided by an embodiment of the present application. The method includes:

[0072] S201: When a synchronous request is received, determine whether the synchronous request needs to call an asynchronous task. If yes, execute step S202. If no, execute step S204.

[0073] In the process of processing a synchronous request, it is necessary to evaluate the content, type, or context of the synchronous request to determine whether some or all of the synchronous request needs to be executed asynchronously.

[0074] S202: After obtaining a unique identifier from a request header of a synchronous request and storing the unique identifier in an MDC of a main thread, a custom thread pool is created.

[0075] In the method disclosed in this application, the created custom thread pool ThreadPoolMonitor inherits from ThreadPoolExecutor. This custom thread pool allows overriding the execute and submit methods so that the MDC information is passed to the child thread before the asynchronous task is executed. Exemplarily, the code for creating a custom thread pool can be as follows:

[0076] / / Create a new custom thread pool ThreadPoolMonitor inherits ThreadPoolExecutor

[0077] public class ThreadPoolMonitor extends ThreadPoolExecutor{}

[0078] S203: When the custom thread pool needs to execute an asynchronous task, the mapping debug context MDC information of the main thread is passed to the MDC of the child thread, so that while the child thread executes the asynchronous task, it can implement log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task.

[0079] In order to realize the transmission of MDC information during asynchronous task execution, two static methods wrap (Runnable, Map<String,String> ) and wrap(Callable <t>,Map<String,String> ). These two methods are used to wrap Runnable or Callable tasks, ensuring that the MDC content is set to the MDC of the current thread before the task is executed, and clearing the MDC after the task is executed to prevent memory leaks. For example, the above code can be:

[0080]

[0081]

[0082] After defining two static methods, in the ThreadPoolMonitor class, rewrite the execute and submit methods and use the wrap method defined above to pass the MDC content of the main thread to the child thread. For example, the above code can be:

[0083]

[0084] Finally, use the custom ThreadPoolMonitor in the application to execute asynchronous tasks. Since the ThreadPoolMonitor has already handled the transmission of MDC information, there is no need to manually set the MDC information when submitting asynchronous tasks. For example, the above code can be as follows:

[0085]

[0086]

[0087] Finally, start the application and call the corresponding request interface. Due to the correct transmission of MDC information, the log will contain the correct traceId even in asynchronous threads.

[0088] S204: Introduce logging framework dependency into the Spring Boot project.

[0089] First, when building a Spring Boot project, in order to effectively manage logs, we need to introduce a logging framework dependency. As a widely used logging facade, slf4j is favored because it can adapt to a variety of logging implementations (such as logback, log4j, etc.). It does not directly provide logging implementations, but allows developers to use different logging frameworks through a unified interface. Next, in the project's pom.xml file, we need to add slf4j-api and logback-related dependencies. The following is a specific dependency configuration example:

[0090]

[0091]

[0092] See also Figure 2B , which is a schematic diagram of an introduction framework provided by an embodiment of the present application. If the project already contains spring-boot-starter-web dependencies, the above-mentioned logback and slf4j dependencies may be automatically introduced, because spring-boot-starter-web is a starter that integrates multiple commonly used dependencies, including log-related dependencies.

[0093] S205: Define the logback-spring.xml file of the logging framework in the resource directory of the project.

[0094] In a Spring Boot project, in order to customize the output format and storage location of the log, we need to define the logback-spring.xml file in the resource directory of the project. This is a specific configuration file for Logback, which is used for log configuration in a Spring Boot environment. Figure 2C , which is a schematic diagram of a configuration file provided by an embodiment of the present application. The logback-spring.xml file allows us to configure the behavior of the log in detail, including the log output format and log storage location of the log.

[0095] Among them, the process of Spring Boot loading the logback-spring.xml configuration file is briefly described as follows:

[0096] The first step is to start and initialize:

[0097] See also Figure 2D , which is a first code schematic diagram provided by the embodiment of the present application. When the Spring Boot application starts, it creates a log system instance to manage the application's logging. Subsequently, by calling the initialize method or other mechanisms, the log system is initialized, including loading configuration, setting log levels, etc.

[0098] The second step is to find the configuration file:

[0099] In a specific implementation, you can search for a custom configuration path. Specifically, if the path and name of the log file are specified through the logging.file configuration item in the application.properties or application.yml file, Spring Boot will first search and load the log file configuration according to this path.

[0100] In another specific implementation, the default configuration path can be searched. Specifically, if the configuration path is not specified through logging.file, Spring Boot will search for the configuration file according to predefined rules or paths (such as logback-spring.xml under src / main / resources). In this process, Spring Boot's automatic configuration mechanism will come into play and try to load configuration files that conform to conventions or are specific to Spring Boot. Exemplarily, getStandardConfigLocations can be called in the getSelfInitializationConfig method to obtain the default configuration path, and the log configuration file can be searched according to the default configuration path. The function of the getStandardConfigLocations method is to return one or more paths representing the possible locations of the log configuration file. These locations are usually the configuration file storage locations expected by the logging framework (such as Logback, Log4j2), such as the logback-spring.xml or log4j2-spring.xml files in the src / main / resources directory. It should be noted that the code for calling getStandardConfigLocations in the getSelfInitializationConfig method to obtain the default configuration path can be as shown in the attached file. Figure 2E See Figure 2E , which is a second code schematic diagram provided in an embodiment of the present application.

[0101] It should be noted that although getStandardConfigLocations is not an abstract method directly provided by the logging system, Spring Boot does automatically find and load logging configuration files according to conventions and configurations, including Logback's logback-spring.xml (if it exists) and logback.xml. This process is implemented through Spring Boot's automatic configuration mechanism, rather than through methods directly provided by the logging system. It should be noted that the code for the file name provided by Logback can be as shown in the attached Figure 2F See Figure 2F , which is a third code schematic diagram provided in an embodiment of the present application.

[0102] The third step is to load the custom configuration file:

[0103] During the search process, Spring Boot pays special attention to configuration files with the -spring suffix (such as logback-spring.xml), because these files usually contain specific configurations for the Spring Boot environment. Once such a file is found, Spring Boot will parse and apply the configuration in it.

[0104] Step 4: Retrieve and load:

[0105] See also Figure 2G , which is a fourth code schematic diagram provided by the embodiment of the present application. Specifically, Spring Boot will retrieve the logback-spring.xml file in the application's classpath. If the file exists, its configuration will be loaded and applied to the log system, thereby controlling the output behavior of the log.

[0106] S206: Obtain a unique identifier from a request header of a synchronous request by modifying the logback-spring.xml file.

[0107] In order to achieve complete link tracing in synchronous requests, you first need to capture the unique identifier generated by the front-end in the gateway request and record this unique identifier in the log file of the back-end service. The unique identifier is usually part of the request header, such as X-B3-TraceId, which can be observed through the browser developer tools.

[0108] Specifically, when a query request is made, you can view the response headers in the browser's developer tools to include headers such as X-B3-TraceId, which stores the traceId of the current request. For example, a typical response header may contain the following information:

[0109] Response Headers:

[0110] Connection:keep-alive

[0111] Content-Type:application / json;charset=UTF-8

[0112] Date:Fri,26Jan 202402:45:39GMT

[0113] Server: nginx

[0114] Transfer-Encoding: chunked

[0115] X-B3-SpanId:a012a24d6582a395

[0116] X-B3-TraceId:d1b6ae7f15b0fe56

[0117] X-GW-SESSION-ID:9365a56e-1684-4c67-970a-222cee97d3c9

[0118] In order to capture and record this traceId in the backend service, we need to modify the logback-spring.xml configuration file. By configuring Logback's PatternLayout or custom Appender, we can extract X-B3-TraceId from the request header of the HTTP request and record it as part of the log message. In this way, every time a request is processed, we can find the corresponding traceId in the log file, thereby achieving complete link tracking of the request.

[0119] S207: In response to the synchronization request, the log framework is used to output the log containing the unique identifier according to the log output format and log storage location indicated by the configuration file to implement log tracking.

[0120] It should be noted that after successfully obtaining a unique identifier (such as traceId) from the request header of the synchronous request through step S206, the unique identifier can also be passed to the asynchronous thread to ensure that the tracking continuity can be maintained in the child thread of the custom thread pool. One way to achieve this goal is to use MDC.getCopyOfContextMap() to capture the MDC (Mapped Diagnostic Context) content of the main thread before submitting the task to the thread pool, and restore the MDC content before the child thread starts executing by wrapping the Runnable or Callable object. In this way, even in the asynchronous thread, we can print out the original traceId and realize cross-thread log tracking.

[0121] Next, we explain how to capture X-B3-TraceId in the logback-spring.xml configuration file:

[0122] See also Figure 2H , which is a schematic diagram of the core elements included in a logback-spring.xml provided in an embodiment of the present application. Fig.2I , which is the fifth code diagram provided by the embodiment of the present application. When configuring logs, you first need to set the Appender, which is the destination of the log output. The configuration of the Appender includes the name and class attributes, where the name is used to customize the name of the Appender for subsequent reference; the class specifies the fully qualified name of the Appender class, which determines the specific way of log output.

[0123] There are various types of Appenders, the most common ones are ConsoleAppender (log output to the console, suitable for local debugging), FileAppender (directly output to files, but because it cannot automatically split files, direct use is not recommended) and RollingFileAppender (a subclass of FileAppender, which supports automatic splitting of log files according to conditions such as file size or time, and is a common choice for application log printing on servers).

[0124] After configuring the Appender, <encoder>and <pattern>Element to define the output format of the log. Figure 2J , which is a sixth code schematic diagram provided in the embodiment of the present application. Among them, <pattern>The %X{X-B3-TraceId:-} in is a key part, which is used to retrieve and output X-B3-TraceId from MDC. The process is as follows: Logback delegates the logging task to Appender, which <class>The type specified by the attribute is instantiated. <encoder>Convert the log information into a byte array and use <pattern>Set the log format. <pattern>When using ch.qos.logback.core.pattern.Converter, Logback will use the implementation class of ch.qos.logback.core.pattern.Converter to identify and convert specific format placeholders, such as %X{X-B3-TraceId:-}, which will be matched and replaced with the X-B3-TraceId value stored in the MDC. Figure 2K , which is a seventh code schematic diagram provided in an embodiment of the present application.

[0125] With the above configuration, we can effectively capture and display traceId in the log, and achieve comprehensive log tracking in both synchronous requests and asynchronous threads.

[0126] In summary, an embodiment of the present application provides a log tracking method, which passes the MDC information of the parent thread to the child thread, ensuring that the log can maintain a consistent context environment during the execution of the asynchronous task, and can track each log in the request link according to the unique identifier (such as traceId) in the MDC information, thereby improving the traceability of the log and reducing the difficulty of subsequent problem tracking and performance analysis.

[0127] See also Figure 3 , which is a schematic diagram of a log tracking device provided in an embodiment of the present application. The log tracking device 300 includes: a creation module 301 and a transmission module 302;

[0128] A creation module 301 is used to create a custom thread pool, where the custom thread pool includes child threads, and the child threads are used to execute asynchronous tasks;

[0129] The transfer module 302 is used to transfer the mapping debugging context MDC information of the main thread to the MDC of the child thread when the custom thread pool needs to execute an asynchronous task, so that the child thread can implement log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task while executing the asynchronous task.

[0130] In a specific implementation, the custom thread pool includes multiple sub-threads, each sub-thread is used to execute a different asynchronous task;

[0131] The transfer module 302 is specifically used to transfer the MDC information of the main thread to the MDC of the target child thread corresponding to the asynchronous task when the custom thread pool needs to execute an asynchronous task, so that the target child thread can realize log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task while executing the asynchronous task.

[0132] In a specific implementation, the log tracking device 300 further includes: a clearing module;

[0133] The clearing module is used to clear the MDC information in the child thread after the child thread completes the asynchronous task.

[0134] In a specific implementation, the creation module 301 is specifically used to: when a synchronous request is received and the synchronous request needs to call an asynchronous task, after obtaining a unique identifier from the request header of the synchronous request and storing the unique identifier in the MDC of the main thread, create a custom thread pool.

[0135] In a specific implementation, the log tracking device 300 further includes: a definition module, a modification module and an output module;

[0136] The definition module is used to define the configuration file of the log framework in the resource directory of the application when a synchronous request is received and the synchronous request does not need to call an asynchronous task. The configuration file is used to configure the log output format and log storage location;

[0137] A modification module is used to obtain a unique identifier from a request header of a synchronous request by modifying a configuration file;

[0138] The output module is used to respond to the synchronization request and use the log framework to output the log containing the unique identifier according to the log output format and log storage location indicated by the configuration file to achieve log tracking.

[0139] To summarize, an embodiment of the present application provides a log tracking device, which passes the MDC information of the parent thread to the child thread, ensuring that the log can maintain a consistent context environment during the execution of the asynchronous task, and can track each log in the request link according to the unique identifier (such as traceId) in the MDC information, thereby improving the traceability of the log and reducing the difficulty of subsequent problem tracking and performance analysis.

[0140] The embodiments of the present application also provide corresponding log tracking devices and computer-readable media for implementing the log tracking methods provided in the embodiments of the present application.

[0141] Among them, the log tracking device includes a memory and a processor, the memory is used to store instructions or codes, and the processor is used to execute instructions or codes so that the device executes a log tracking method of any embodiment of the present application.

[0142] See also Figure 4 , which is a schematic diagram of a computer-readable medium provided in an embodiment of the present application. The computer-readable medium 400 stores a computer program 411, which implements the above-mentioned Figure 1 The steps of the log tracking method.

[0143] It should be noted that in the context of the present application, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0144] It should be noted that the machine-readable medium mentioned above in the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0145] The computer-readable medium may be included in the electronic device, or may exist independently without being installed in the electronic device.

[0146] Although the subject matter has been described in language specific to structural features and / or methodological logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims.

[0147] Although several specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present application. Certain features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination.

[0148] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in this application (but not limited to) by each other to form a technical solution.< / pattern> < / pattern> < / encoder> < / class> < / pattern> < / pattern> < / encoder> < / t>

Claims

1. A log tracking method, characterized in that: The method comprises: Creating a custom thread pool, wherein the custom thread pool includes child threads, and the child threads are used to execute asynchronous tasks; When the custom thread pool needs to execute the asynchronous task, the mapping debugging context MDC information of the main thread is passed to the MDC of the child thread, so that while the child thread executes the asynchronous task, it realizes log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task.

2. The method according to claim 1, characterized in that After executing the step of transferring the mapping debugging context MDC information of the main thread to the MDC of the child thread, the method further includes: When the child thread completes executing the asynchronous task, the MDC information in the child thread is cleared.

3. The method according to claim 1, characterized in that The step of creating a custom thread pool includes: When a synchronous request is received and the synchronous request needs to call an asynchronous task, a custom thread pool is created after obtaining a unique identifier from a request header of the synchronous request and storing the unique identifier in the MDC of the main thread.

4. The method according to claim 1, characterized in that: The method further comprises: When a synchronous request is received, and the synchronous request does not need to call an asynchronous task, a configuration file of the log framework is defined in the resource directory of the application, and the configuration file is used to configure the log output format and the log storage location; By modifying the configuration file, a unique identifier is obtained from the request header of the synchronization request; In response to the synchronization request, the log framework is used to output the log containing the unique identifier according to the log output format and log storage location indicated by the configuration file to achieve log tracking.

5. The method according to claim 1, characterized in that The custom thread pool includes multiple sub-threads, each of which is used to execute a different asynchronous task; When the custom thread pool needs to execute the asynchronous task, the mapping debugging context MDC information of the main thread is passed to the MDC of the child thread, so that the child thread implements log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task while executing the asynchronous task, including: When the custom thread pool needs to execute the asynchronous task, the MDC information of the main thread is passed to the MDC of the target child thread corresponding to the asynchronous task, so that the target child thread can realize log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task while executing the asynchronous task.

6. A log tracking device, characterized in that: The device comprises: a creation module and a transmission module; The creation module is used to create a custom thread pool, the custom thread pool includes child threads, and the child threads are used to execute asynchronous tasks; The transfer module is used to transfer the mapping debugging context MDC information of the main thread to the MDC of the child thread when the custom thread pool needs to execute the asynchronous task, so that the child thread can realize log tracking by tracking the unique identifier in the MDC information in the request link corresponding to the asynchronous task while executing the asynchronous task.

7. The device according to claim 6, characterized in that The device further comprises: a clearing module; The clearing module is used to clear the MDC information in the child thread after the child thread completes executing the asynchronous task.

8. The device according to claim 6, characterized in that The creation module is specifically used for: when a synchronous request is received and the synchronous request needs to call an asynchronous task, after obtaining a unique identifier from a request header of the synchronous request and storing the unique identifier in the MDC of the main thread, creating a custom thread pool.

9. A log tracking device, characterized in that: The device comprises: a memory and a processor; The memory is used to store programs; The processor is used to execute the program to implement each step of the log tracking method according to any one of claims 1 to 5.

10. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, each step of the log tracking method according to any one of claims 1 to 5 is implemented.

Images