A method, system, product, and medium for log link tracing of concurrent requests

Abstract

A log link tracking method, system, product and medium for concurrent requests, wherein the method comprises: in response to a concurrent request, matching a business analysis rule corresponding to the concurrent request from a preset rule library; dynamically analyzing corresponding business dimension data from the request message of the concurrent request; sequentially combining the business dimension data through a preset separator to generate a structured link tracking identifier; generating a tracking context environment bound to the concurrent request; in response to a business log output instruction, extracting the structured link tracking identifier from the tracking context environment, and splicing the structured link tracking identifier with the log text corresponding to the business log output instruction according to a preset layout mode to obtain a link tracking log record; and sending the link tracking log record to a log retrieval end to enable the log retrieval end to obtain a log link tracking result in response to a log retrieval request. The application improves the log link tracking efficiency in a complex concurrent environment.

Description

Technical Field

[0001] This application relates to the field of log tracing technology, specifically to a log tracing method, system, product, and medium for concurrent requests. Background Technology

[0002] With the continuous development of distributed architecture and microservice technology in the Internet, the number of concurrent requests to business servers is growing exponentially. When a single user request enters the system, it often triggers cascading calls from multiple upstream and downstream business nodes. In order to monitor the flow of requests and locate system faults in a massive concurrent environment, distributed tracing and log collection systems (such as log retrieval terminals) have become indispensable basic infrastructure.

[0003] In existing technologies, when concurrent requests reach the system's gateway or ingress interceptor, the system typically automatically generates a globally unique, purely random string (e.g., a meaningless Trace ID generated based on a universally unique identifier UUID) as the link tracing identifier for the request. This string is then passed through and logged between nodes along with the request. When a business node executes and outputs a log, the logging framework directly appends this random string to the log text before finally sending it to the log center. When troubleshooting, technical personnel primarily rely on searching for this specific random string in massive amounts of concurrent logs to connect scattered logs belonging to the same request.

[0004] However, in real-world high-concurrency production environments, the initial clues for troubleshooting are often explicit business-level parameters (such as customer complaints targeting a specific channel number or business order number). If only random identifiers are used, the log retrieval system needs to first perform complex correlation queries to "translate" the business documents into random strings corresponding to the requests before a secondary retrieval can be performed. While existing distributed tracing systems (such as Zipkin and Jaeger) support custom tags, they require additional deployment of tracing agents and modification of business code for data entry, increasing system complexity and maintenance costs. This significantly reduces the efficiency of log tracing in complex concurrent environments. Summary of the Invention

[0005] This application provides a method, system, product, and medium for log tracing of concurrent requests, which can improve the efficiency of log tracing in complex concurrent environments.

[0006] The first aspect of this application provides a log tracing method for concurrent requests, characterized in that it is applied to a business server, and the method includes: In response to concurrent requests, based on the request header features and routing address of the concurrent requests, a business parsing rule corresponding to the concurrent request is matched from a preset rule base. The business parsing rule defines the set of fields and extraction paths for the link tracing dimensions to be extracted for different business scenarios. Based on the extraction path, the corresponding business dimension data is dynamically parsed from the request messages of the concurrent requests; According to the hierarchical splicing order defined in the business parsing rules, the business dimension data is combined in an orderly manner through preset delimiters to generate a structured link tracing identifier with business semantics. The position of each level of the structured link tracing identifier corresponds to the order of the field set. The structured link tracing identifier is written as a custom variable into the log diagnostic context of the thread currently processing the concurrent request, thereby obtaining a tracing context environment bound to the concurrent request. The tracing context environment is used to isolate the current request tracing state in a concurrent environment. In response to the business log output instruction, the structured link tracing identifier is extracted from the tracing context environment, and the structured link tracing identifier is concatenated with the log text corresponding to the business log output instruction according to a preset layout pattern to obtain a link tracing log record containing business semantics; The link tracing log records are sent to the log retrieval terminal, so that the log retrieval terminal responds to the log retrieval request, locates the data in the link tracing log records based on the structured link tracing identifier, and obtains the log link tracing result.

[0007] Optionally, based on the extraction path, the corresponding business dimension data is dynamically parsed from the request messages of the concurrent requests, specifically including: Based on the extraction path in the business parsing rules, the field set is divided into a first type of field located in the header area of ​​the request message and a second type of field located in the payload area of ​​the request message. Parse the environmental dimension data corresponding to the first type of field from the header region; When the data volume of the load area is greater than the preset memory safety threshold, a streaming read cursor with a state tracking task is bound to the data stream of the load area. The state tracking task contains all the node paths to be matched corresponding to the second type of field. Based on the state tracking task, the streaming read cursor is driven to intercept and scan the data stream to obtain the corresponding target features; When the data volume of the load region is less than or equal to the preset memory safety threshold, the load region is fully parsed based on the addressing expression corresponding to the second type of field to obtain the corresponding target feature; The environmental dimension data is assembled with the target features to obtain the business dimension data.

[0008] Optionally, based on the state tracking task, the streaming cursor is driven to intercept and scan the data stream to obtain the corresponding target features, specifically including: The streaming cursor is driven to scan the data stream step by step downwards. When the current node path scanned is consistent with the target path, the current node path is determined as the matching path. The node data content corresponding to the matching path is extracted as the target feature, and the target path corresponding to the matching path is deregistered from the state tracking task. The target path is any path among the node paths to be matched. When all the matching node paths in the state tracking task have been cancelled, in response to the full load interruption mechanism, a safe short-circuit instruction is triggered to terminate the scanning of the remaining unread content of the data stream by the streaming read cursor.

[0009] Optionally, based on the addressing expression corresponding to the second type of field, a full memory parsing is performed on the load region to obtain the corresponding target features, specifically including: Based on the addressing expression corresponding to the second type of field, the payload region of the request message is converted into a memory node tree; The memory node tree is traversed and matched to extract the service carrier identifier sent by the access party. The business carrier identifier is converted into a string format to obtain the target feature.

[0010] Optionally, according to the hierarchical concatenation order defined in the business parsing rules, the business dimension data is sequentially combined using preset delimiters to generate a structured link tracing identifier with business semantics, specifically including: Based on the location index sequence in the business parsing rules, the variable values ​​of the corresponding dimensions are extracted sequentially from the business dimension data to construct a data sequence to be spliced ​​containing the order of events. The location index sequence is used to define the tracking dimensions of each link. Detect missing nodes and conflicting node data containing the preset delimiter in the data sequence to be spliced; The empty nodes are filled with default placeholders, and the conflicting characters in the conflicting node data are escaped and replaced to obtain the cleaned standard data sequence. Traverse the standard data sequence, insert the preset separator between two adjacent data units and concatenate the strings to obtain the structured link tracing identifier.

[0011] Optionally, the structured tracing identifier is written as a custom variable into the log diagnostic context of the thread currently processing the concurrent request, to obtain a tracing context environment bound to the concurrent request, specifically including: Identify the application-level thread currently executing the concurrent request and invoke the mapping diagnostic context component of the system's underlying log processing framework; Based on a preset thread-local storage mechanism, the reused historical context cache data in the application-level thread is cleared, and an isolation copy of the variable is initialized for the concurrent request; The structured link tracing identifier is mapped and bound to the feature key name pre-registered in the log processing framework to generate tracing key-value pairs; The tracking key-value pairs are written to the variable isolation copy to obtain the tracking context environment.

[0012] Optionally, the structured link tracing identifier is concatenated with the log text corresponding to the business log output instruction according to a preset layout pattern to obtain a link tracing log record containing business semantics, specifically including: Intercept the log events generated by the business log output command and wake up the formatting component of the underlying log processing framework of the system; The structured link tracing identifier is dynamically retrieved from the tracing context by using a custom transformation rule node pre-configured in the formatting component. Load the log output template corresponding to the preset layout mode. The log output template includes native placeholders for carrying the original log content and custom placeholders for declaring extended tracking dimensions. The log text is filled into the corresponding native placeholder to obtain the business content data segment, and the structured link tracing identifier is filled into the corresponding custom placeholder to obtain the tracing identifier data segment; According to the placeholder arrangement order in the log output template, the tracking identifier data segment and the business content data segment are concatenated to obtain the link tracing log record.

[0013] In a second aspect, embodiments of this application provide a concurrent request log link tracing system, the concurrent request log link tracing system comprising: one or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the concurrent request log link tracing system to perform the method as described in the first aspect and any possible implementation thereof.

[0014] Thirdly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a concurrent request log tracing system, cause the concurrent request log tracing system to perform the method described in the first aspect and any possible implementation thereof.

[0015] Fourthly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a concurrent request log tracing system, cause the concurrent request log tracing system to execute the method described in the first aspect and any possible implementation thereof.

[0016] In summary, one or more technical solutions provided in this application have at least the following technical effects or advantages: 1. By introducing business parsing rules, the system transforms meaningless random identifiers into structured tracing identifiers with business semantics: Based on request header features and routing address matching business parsing rules, business dimension data is dynamically parsed from the request message and concatenated hierarchically to generate a structured identifier. This identifier is then associated with the log text and sent to the log retrieval terminal. This allows operations personnel to directly and accurately locate information in the log retrieval terminal based on known business clues (such as channel numbers and business order numbers) without the need for secondary conversion of random identifiers. This effectively solves the problem of broken retrieval links in existing technologies and improves log tracing efficiency in complex concurrent environments.

[0017] 2. When parsing business dimension data from request messages, a dynamic divide-and-conquer parsing mechanism based on load volume is further introduced: The field set is divided into a first type of field in the header region and a second type of field in the load region according to the extraction path. Environment dimension data is parsed from the header region. When the load region data volume exceeds a preset memory safety threshold, a streaming read cursor with a state tracking task is bound to the data stream. The data stream is intercepted and scanned based on the path of the node to be matched. After all target paths are matched, a safety short-circuit instruction is triggered through a full-load interrupt mechanism to terminate the scan. When the load volume is less than or equal to the threshold, full memory parsing is performed based on the addressing expression. Through this mechanism, this invention achieves low-memory consumption parsing of large-volume load data, avoiding the risk of memory overflow caused by full loading of large messages. Simultaneously, the state tracking and safety short-circuit mechanisms significantly reduce invalid scans, improving the parsing efficiency of business dimension data while ensuring system stability, and providing reliable support for the rapid generation of structured link tracing identifiers.

[0018] 3. When performing full memory parsing based on addressing expressions, a business carrier identifier extraction mechanism based on memory node tree traversal is further introduced: the load area of ​​the request message is converted into a memory node tree, traversal and matching are performed in the memory node tree, the business carrier identifier sent by the access party is extracted, and it is converted into a string format to obtain the target feature. Through this mechanism, this invention achieves accurate positioning and unified format conversion of business carrier identifiers within the load area, ensuring that the business dimension data extracted from the request message remains semantically consistent with the original business clues. This provides a reliable data foundation for the accurate generation of structured link tracing identifiers, avoids retrieval failures caused by deviations in business carrier identifier parsing, and further improves the accuracy and reliability of log link tracing. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a log tracing method for concurrent requests in an embodiment of this application; Figure 2 This is a flowchart illustrating the process of determining business dimension data in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a log tracing system for concurrent requests provided in an embodiment of this application.

[0020] Explanation of reference numerals in the attached drawings: 301, Central Processing Unit; 302, Read-Only Memory; 303, Random Access Memory; 304, Bus; 305, Input / Output Interface; 306, Input Section; 307, Output Section; 308, Storage Section; 309, Communication Section; 310, Driver; 311, Removable Media. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0022] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0023] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0024] In this application, the business server acts as the data source and core processing node for log tracing. Upon receiving concurrent requests, the business server first matches business parsing rules based on the request header and route, and dynamically selects a parsing strategy based on the request packet load (using a streaming cursor for safe short-circuit scanning when limits are exceeded, and performing full memory parsing when limits are not exceeded) to extract business-dimensional data. Subsequently, the server cleans the extracted data and concatenates it hierarchically into a structured tracing identifier with business semantics. After clearing the thread history cache, it writes it into the log diagnostic context (such as MDC) of the current processing thread to achieve thread-level isolation in a concurrent environment. Finally, the server intercepts log output commands generated during business flow, and concatenates the structured identifier with the native log text according to a template through the underlying log framework to generate a tracing log record containing business semantics and sends it downstream.

[0025] As the aggregation, storage, and analysis center for log data, the log retrieval terminal continuously receives trace log records sent from various business server nodes. It then builds an efficient retrieval engine and data index based on the structured trace identifiers (such as combined fields containing tenant, user, and business order number dimensions) in the logs, which are combined according to preset delimiters. When it receives a log retrieval request initiated by operations or development personnel, the log retrieval terminal does not need to rely on the traditional meaningless system-level TraceID. Instead, it directly responds to the business keywords carried in the request and performs accurate data location and filtering based on the structured trace identifier in the massive concurrent log library. This allows it to quickly aggregate log sequences that are completely bound to specific business actions, generate and return complete log trace results.

[0026] In actual high-concurrency system interactions (taking e-commerce order placement as an example), when a massive influx of requests occurs, the business server intercepts the requests in real time, dynamically extracts features such as "tenant ID, user ID, and order number," and concatenates them into a structured identifier such as "TenantA|User123|Order888." This identifier is then isolated and bound to the current processing thread. During subsequent business nodes such as inventory deduction and payment, this identifier is automatically and seamlessly injected into each business log and asynchronously transmitted to the log retrieval end. Upon receiving these logs, the log retrieval end immediately persists and indexes them by features. When an order anomaly occurs, investigators only need to enter the specific "order number (Order888)" into the log retrieval end to initiate a search. The log retrieval end can then instantly and accurately extract the entire link log record of the order from initiation to failure from the complex concurrent log stream by matching this structured identifier. This achieves efficient closed-loop interaction between the business server "producing isolated logs based on business semantics" and the log retrieval end "accurately reconstructing the link based on business semantics."

[0027] Figure 1 This is a flowchart illustrating a concurrent request log tracing method according to an embodiment of this application.

[0028] Please see Figure 1 This application provides a method for log tracing of concurrent requests, applied to a business server. The method includes: S101. In response to a concurrent request, based on the request header features and routing address of the concurrent request, a business parsing rule corresponding to the concurrent request is matched from a preset rule base. The business parsing rule defines the set of fields and extraction paths of the link tracing dimensions required to be extracted for different business scenarios. In the initial stage when the business server receives high-concurrency requests, to address the problem of traditional link tracing identifiers (such as UUIDs) lacking business semantics and thus struggling to accurately trace back in complex business scenarios, the business server first executes step S101. Responding to concurrent requests, the business server uses a built-in traffic interceptor to capture the request header characteristics and routing addresses of the concurrent requests in real time. Concurrent requests refer to a large number of network access requests initiated simultaneously by multiple external terminal devices or upstream systems to the business server within the same time period. Concurrent requests trigger the business server to allocate multiple independent threads for parallel processing, resulting in massive and intertwined runtime logs in the system. The request header characteristics refer to metadata information hidden in the request message header that describes the request source, terminal type, or tenant attributes, while the routing address refers to the specific business interface path pointed to by the request. The business server uses request header features and routing addresses as retrieval keys to match against a pre-defined rule base. This rule base is a pre-configured set of mapping relationships stored in the business server's memory or configuration center. Its purpose is to store the correspondence between different request features and processing logic, and it works by quickly locating the target configuration using hash matching or prefix tree algorithms. Through the matching operation, the business server obtains the business parsing rules corresponding to concurrent requests. These business parsing rules are statically defined configuration templates, and their core purpose is to provide navigation for subsequent feature extraction. The business parsing rules define the set of fields and extraction paths for the link tracing dimensions required for different business scenarios. The field set refers to a set of tag names reflecting key business information (such as order number, user ID, store number, etc.), and the extraction path refers to the specific addressing logic of these tags in the request message (such as JSON path expressions or regular expressions). Through step S101, the business server can automatically identify the business scenario to which the current request belongs based on the request's entry characteristics, thereby tailoring a differentiated tracing dimension extraction scheme for each concurrent request, ensuring that the subsequently generated tracing identifiers have a high degree of business relevance.

[0029] For example, when the business server receives a concurrent request pointing to the route address " / trade / order / create" and the request header contains "Terminal-Type:Mobile", the business server matches a business parsing rule named "Mobile Order Rule" in the preset rule base. The business parsing rule explicitly defines the field set as "{Tenant ID, User ID, Order Number}" and specifies the extraction paths as the "X-Tenant-Id" field in the request header and the paths "$.userInfo.id" and "$.orderInfo.no" in the request body JSON.

[0030] S102. Based on the extraction path, dynamically parse the corresponding business dimension data from the request message of the concurrent request; After obtaining the business parsing rules, the business server executes step S102 to efficiently and securely extract key information for tracking from complex concurrent requests, avoiding server memory overflow or performance degradation caused by brute-force parsing. Based on the extraction path provided in the business parsing rules, the business server dynamically parses the request messages of concurrent requests. A request message refers to a complete network data packet sent by the client to the server, typically containing metadata for controlling routing and the data body carrying core business logic. Business dimension data refers to the specific numerical values ​​or strings extracted from the request message that uniquely identify or classify the current business behavior. Considering that request messages are usually composed of different regions, and the size of the regions carrying business data varies, the business server does not use a single static parsing method. Instead, it needs to dynamically adopt a region-based, component-level parsing strategy based on the extraction path and the actual size of the message, balancing parsing efficiency and memory safety to accurately obtain the corresponding business dimension data. Specifically, this may include the following steps: Figure 2 This is a flowchart illustrating the process of determining business dimension data in an embodiment of this application. The following is a summary of the process. Figure 2 A detailed explanation of step S102 is provided below: S201. Based on the extraction path in the business parsing rules, the field set is divided into a first type of field located in the header area of ​​the request message and a second type of field located in the payload area of ​​the request message. The request messages from concurrent requests exhibit significant regional differences in their physical structure. The data volume and parsing costs vary considerably across different regions. If parsed uniformly without differentiation, this can easily lead to server memory overflow or CPU resource exhaustion when dealing with extremely large messages. Therefore, the business server, based on the extraction path in the business parsing rules, divides the field set into two categories: the first category of fields located in the header area of ​​the request message, and the second category of fields located in the payload area. The request message header area originates from the specification definition of standard network communication protocols (such as HTTP). Its purpose is to carry additional control information and environmental metadata for network requests. It works by using simple key-value pairs for lightweight transmission in plaintext format, typically resulting in a very small size and easy readability. The request message payload area also originates from network communication protocol specifications. Its purpose is to transmit core business entity data. It works by serializing and encapsulating complex business objects using specific encoding formats (such as JSON, XML, or binary streams), typically resulting in a larger size and more complex structure. The first and second categories of fields are logical classification tags defined by the business server to differentiate subsequent parsing strategies.

[0031] In practice, the business server reads the extraction path corresponding to each field in the business parsing rules one by one. It then uses a string matching algorithm to identify the region prefix identifier carried in the extraction path. If the region prefix identifier points to the header region, the business server classifies the corresponding field as a first-category field; if the region prefix identifier points to the load region, the business server classifies the corresponding field as a second-category field. Through step S201, the business server successfully decouples the physical location of the fields to be extracted, laying a solid foundation for subsequent differentiated parsing strategies of "lightweight direct reading" and "heavyweight on-demand streaming reading" for different regions. This significantly improves parsing efficiency and completely eliminates memory safety risks.

[0032] For example, when the business parsing rules require the extraction of "tenant ID" and "order amount", the business server reads that the extraction path prefix for "tenant ID" is "Header." and the extraction path prefix for "order amount" is "Body." The business server then classifies "tenant ID" as the first type of field located in the header area of ​​the request message and classifies "order amount" as the second type of field located in the payload area of ​​the request message.

[0033] S202. Parse the environmental dimension data corresponding to the first type of field from the header region; The header area of ​​request messages typically uses a standard key-value pair format for plaintext encoding. The data size is small and resides in the initial receiving memory of the business server; directly reading the header area poses no risk of memory overflow. Therefore, the business server prioritizes parsing the environment dimension data corresponding to the first type of fields from the header area. Environment dimension data is a basic classification label defined by the business server to distinguish core business payloads. It originates from system-level metadata automatically attached by the client, browser, or API gateway when a network request is initiated. The purpose of environment dimension data is to identify the macro-level business environment, tenant isolation status, or terminal device type of concurrent requests. The principle behind environment dimension data is cross-node transparent transmission based on standard header fields of the underlying network communication protocol.

[0034] In the specific implementation process, the business server iterates through the set of the first type of fields, calls the header reading interface provided by the underlying network communication framework, uses the extraction path corresponding to the first type of field as the target key name, and directly performs a hash lookup in the key-value pair mapping table in the header area to accurately extract the corresponding numerical value or string as environment dimension data. Through step S202, the business server successfully obtains the basic environment prefix for building the structured link tracing identifier in a very short time and without increasing the additional memory burden, laying the top-level classification foundation for the subsequent generation of complete tracing identifiers with business semantics.

[0035] For example, when the first type of field contains "tenant identifier" and the corresponding extraction path is "X-Tenant-ID", the business server directly calls the header reading interface to find the key-value pair with the key name "X-Tenant-ID" in the header area and extracts the corresponding value "Tenant_888" as the environment dimension data.

[0036] S203. When the data volume of the load area is greater than the preset memory safety threshold, bind a streaming read cursor with a state tracking task to the data stream of the load area. The state tracking task includes all the node paths to be matched corresponding to the second type of field. The business server first obtains the data volume of the load region and compares it in real time with a preset memory safety threshold. The preset memory safety threshold is a pre-set byte limit used to measure memory capacity. Its purpose is to determine the switching of parsing strategies. The principle behind the preset memory safety threshold is to avoid memory overflow risks by comparing the byte length of the request packet load region with a preset value. When the data volume of the load region exceeds the preset memory safety threshold, the business server abandons the full load mode and instead binds a streaming read cursor with a state tracking task to the data stream of the load region. A streaming read cursor is a pointer-based data reading component. Its purpose is to perform sequential scanning without loading all data into memory. The principle of a streaming read cursor is to maintain an offset pointing to the current read position of the data stream and read small blocks of data as needed. A state tracking task is a logical set used to record matching progress. Its purpose is to coordinate the scanning behavior of a streaming cursor. The principle behind a state tracking task is to transform the paths of fields to be extracted into a set of state nodes to be triggered. A state tracking task includes all the node paths to be matched corresponding to the second type of fields. The business server has built a lightweight, event-driven parsing environment, enabling it to capture business characteristics in real time during data flow. This ensures system security while achieving efficient feature extraction from large packets.

[0037] For example: If the data volume of the load area is 100MB and the preset memory safety threshold is 10MB, the business server will identify that the data volume of the load area exceeds the preset memory safety threshold. Then, it will initialize a status tracking task containing "order number path" and "product ID path" and attach a streaming read cursor to the 100MB data input stream, ready to extract data on demand during the data flow.

[0038] S204. Based on the state tracking task, drive the streaming read cursor to intercept and scan the data stream to obtain the corresponding target features; After successfully binding a streaming read cursor and a state tracking task to a large load area, the business server executes step S204 to accurately and efficiently extract the required business dimension data from the massive amount of data. The business server uses the state tracking task as dynamic navigation, driving the streaming read cursor to perform real-time interception scanning in the data stream. Considering that only a very small portion of the data in a large packet is often necessary for link tracing, if the streaming read cursor continues reading until the end of the data stream, it will still cause unnecessary consumption of CPU time slices and waste of network I / O resources. Therefore, during the interception scanning process, the business server must introduce a dynamic matching and interruption mechanism that scans and verifies simultaneously and can immediately stop losses after the task is completed. This allows the streaming read cursor to intelligently terminate the reading of the remaining useless data after accurately extracting the corresponding target features, thereby minimizing the consumption of system resources. Specifically, this includes the following steps: The streaming cursor is driven to scan the data stream step by step downwards. When the current node path scanned is consistent with the target path, the current node path is determined as the matching path. The node data content corresponding to the matching path is extracted as the target feature, and the target path corresponding to the matching path is deregistered from the state tracking task. The target path is any path among the node paths to be matched. When all the matching node paths in the state tracking task have been cancelled, in response to the full load interruption mechanism, a safe short-circuit instruction is triggered to terminate the scanning of the remaining unread content of the data stream by the streaming read cursor.

[0039] In practice, the business server drives a streaming cursor to scan the data stream level by level. The goal is to accurately capture the required business dimension data from a large load area with minimal memory usage, while avoiding duplicate matching. During the scan, the streaming cursor generates a current node path in real time. This current node path originates from a hierarchical state tree dynamically maintained by the data stream parsing engine during byte-by-byte or level-by-level reading. Its purpose is to accurately represent the physical hierarchical position of the streaming cursor at the current moment. This is achieved by recording the depth and keys of nested structures (such as JSON objects or XML tags) through push and pop operations. The business server performs a real-time string comparison between the scanned current node path and the target path included in the state tracking task. The target path can be any path among the node paths to be matched. When the scanned current node path matches the target path, the business server determines the current node path as the matching path and immediately extracts the node data content corresponding to the matching path as the target feature. To maintain the real-time performance of the state tracking task and narrow down the subsequent comparison range, the business server then deregisters the target path corresponding to the matching path from the state tracking task. By performing the above operations, the business server not only achieved accurate stripping of target features, but also dynamically reduced the set to be matched, greatly improving the comparison efficiency of subsequent scans.

[0040] For example, when the streaming cursor scans to the ".order.id" level, the business server finds that ".order.id" is completely consistent with a target path in the state tracking task. It then identifies ".order.id" as the matching path, extracts the corresponding node data content "Order_12345" as the target feature, and removes ".order.id" from the state tracking task. At this point, only ".user.id" remains in the state tracking task waiting to be matched.

[0041] During the continuous cancellation of target paths, the business server continuously monitors the internal state of the state tracing task, aiming to release system resources immediately after achieving the extraction target. When all matching node paths in the state tracing task have been cancelled, it means that the business server has fully obtained all the target characteristics required for the current concurrent request. Continuing to read the data stream would be meaningless and would waste CPU time slices and network I / O resources. At this point, the business server responds to the full-load interrupt mechanism. The full-load interrupt mechanism originates from the system's underlying resource optimization strategy. Its purpose is to break the normal complete data stream reading loop. The principle is to block the sequential execution of the program by changing the control flag or throwing a specific control flow exception when the task queue clearing condition is met. The business server triggers a safe short-circuit instruction based on the full-load interrupt mechanism. The safe short-circuit instruction originates from the underlying flow control framework. Its purpose is to gracefully cut off the data stream connection and reclaim the underlying handle. The principle is to call the termination method of the network socket or file stream. The business server uses the safe short-circuit instruction to forcibly terminate the scanning of the remaining unread content of the data stream by the streaming read cursor. By executing the above interruption operation, the business server achieves extreme performance optimization in high-concurrency scenarios. Even when faced with ultra-large packets of hundreds of megabytes, as long as the target feature is located at the beginning of the packet, the business server can complete the extraction in milliseconds and instantly cut off the reading, completely avoiding unnecessary resource occupation.

[0042] For example: Continuing from the previous example, when the streaming cursor continues scanning and successfully extracts the value corresponding to "$.user.id", the last node path to be matched in the state tracking task is cancelled, the state tracking task becomes an empty set, and the business server immediately responds to the full load interruption mechanism to trigger a safety short-circuit instruction, directly shutting down the data stream, so that the remaining 99MB of irrelevant data such as product details are not read and parsed.

[0043] S205. When the data volume of the load area is less than or equal to the preset memory safety threshold, the load area is fully parsed based on the addressing expression corresponding to the second type of field to obtain the corresponding target feature. When the business server detects that the data volume of the load area is less than or equal to the preset memory safety threshold, it indicates that loading the entire load area into memory is within the safe range of the system's carrying capacity, and that direct structured parsing in memory can achieve the optimal processing speed. When the volume condition is met, the business server abandons the complex streaming interception mechanism and instead performs full memory parsing of the load area of ​​the request packet based on the addressing expression corresponding to the second type of field. Specifically, this may include the following steps: converting the load area of ​​the request packet into a memory node tree based on the addressing expression corresponding to the second type of field; traversing and matching within the memory node tree to extract the business carrier identifier sent by the access party; and converting the business carrier identifier into a string format to obtain the target feature.

[0044] In the specific implementation process, after ensuring that the data volume of the load area is within a safe range, in order to efficiently and accurately address and extract structured data in memory, the business server converts the load area of ​​the request message into a memory node tree based on the addressing expression corresponding to the second type of field. The load area typically appears as a flat byte stream or long string during network transmission. Directly performing regular expression matching on flat data is not only inefficient but also prone to misjudgments due to format nesting. Therefore, the business server calls a deserialization parsing engine that matches the addressing expression to completely load the data of the load area into memory for structured reorganization. The memory node tree originates from tree data structures in computer science. Its purpose is to completely map the hierarchical relationships of complex nested data (such as JSON or XML) in system memory. The principle of the memory node tree is to connect parent and child pointers within node objects to form a multi-branch tree model containing root nodes, branch nodes, and leaf nodes. By performing the above transformation operation, the business server successfully transforms the unordered and difficult-to-manipulate byte stream into a structured model that can be quickly traversed and accurately located by the program, paving the way for subsequent feature extraction. For example, when the load area is a JSON string containing order information, the business server calls the JSON parsing engine based on the address expression "$.order.id" to deserialize the JSON string into an in-memory node tree. The in-memory node tree contains a root node and "order" branch nodes and "id" leaf nodes nested under the root node.

[0045] After constructing the memory node tree, the business server traverses and matches within it to extract the business carrier identifier sent by the access party. The business server breaks down the addressing expression into multiple hierarchical path fragments, starting from the root node of the memory node tree and performing a depth-first or breadth-first traversal layer by layer according to the instructions of the hierarchical path fragments. During the traversal, the business server continuously compares the key name of the current node with the path fragment for consistency until it accurately locates the final leaf node pointed to by the addressing expression. Upon successful location, the business server extracts the business carrier identifier sent by the access party from the leaf node. The business carrier identifier originates from the domain modeling definition of the core entity in the business system. Its purpose is to uniquely identify the specific business object operated on by the current concurrent request (such as a transaction order number, payment serial number, or user account). The business carrier identifier is generated proactively by the external access party calling the interface when initiating a network request, according to the interface contract agreed upon by both parties, and encapsulated in the request message before being sent to the business server. By traversing and matching within the memory node tree, the business server accurately extracts core business data strongly related to the current concurrent requests from the massive and complex message structure. For example: Continuing from the previous example, the business server traverses downwards along the "order" node in the memory node tree, successfully matching the "id" leaf node, and extracts the business carrier identifier "ORD-20231001" sent by the access party from the "id" leaf node.

[0046] After extracting the core business data, considering that the business carrier identifier may appear in various different data types (such as integer, long integer, or boolean) in the original message, the business server converts the business carrier identifier into a string format to obtain the target feature, ensuring seamless concatenation according to the preset delimiter. The business server calls the type conversion function or serialization interface provided by the underlying programming language to force type smoothing of the extracted business carrier identifier, uniformly formatting it into a standard text string. The target feature is a standardized data source prepared by the business server to construct the structured link tracing identifier. By performing the type conversion operation, the business server completely eliminates the differences in underlying data types, avoiding program exceptions caused by type mismatches when generating the structured link tracing identifier, and ensuring the absolute stability and compatibility of the entire link tracing context concatenation process. For example, if the extracted business carrier identifier is a long integer value "987654321", the business server calls the type conversion function to convert the long integer value into the text format "987654321", thus obtaining the final target feature used for concatenation.

[0047] S206. Assemble the environmental dimension data with the target features to obtain the business dimension data.

[0048] After data extraction is completed from the header region and the load region respectively, since the previous parsing process is based on the separation of different physical regions of the message, the extracted environmental dimension data and target features are in a discrete state in the system memory. In order to generate a unified tracking identifier according to business semantics in the subsequent process, the business server executes step S206.

[0049] The business server assembles environmental dimension data with target features to obtain business dimension data. This assembly originates from data aggregation operations in software engineering. Its purpose is to integrate multi-source heterogeneous data into a unified context carrier. The principle of assembly is to create new data set objects in memory, storing discrete variable references into a unified, contiguous memory space. Business dimension data originates from indicator definitions in the business monitoring and diagnostics domain. Its purpose is to serve as a complete raw material library for building the final link tracing identifier. The principle of business dimension data is to include a set of all key features of current concurrent requests at both the macro-environment and micro-business levels.

[0050] In practice, the business server initializes a standard key-value pair set in memory. Then, it maps and binds environmental dimension data and target features to the original field names defined in the business parsing rules, and writes them uniformly into the key-value pair set. By performing the assembly operation, the business server successfully transforms scattered information from different physical regions across network requests into a logically complete and structurally unified feature set, completely shielding the differences in underlying parsing methods and providing standardized data input for subsequently generating structured link tracing identifiers strictly according to hierarchical order.

[0051] For example, when the extracted environment dimension data is the tenant identifier "Tenant_888" and the extracted target feature is the order number "ORD-20231001", the business server initializes a hash table in memory and stores "Tenant_888" and "ORD-20231001" into the hash table, thereby obtaining business dimension data containing complete request context information.

[0052] S103. According to the hierarchical splicing order defined in the business parsing rules, the business dimension data is combined in an orderly manner through a preset delimiter to generate a structured link tracing identifier with business semantics. The position of each level of the structured link tracing identifier corresponds to the order of the field set. After successfully extracting and assembling complete business dimension data, the business server must convert the discrete feature set in memory into a unified string format to achieve efficient automated retrieval and multi-dimensional business status tracking in massive concurrent logs. Therefore, step S103 is executed. The business server does not arbitrarily concatenate the business dimension data; instead, it strictly follows the predefined hierarchical concatenation order in the business parsing rules, using preset delimiters to orderly combine the business dimension data. In the actual combination process, considering that the data extracted from real network requests may have missing fields or contain conflicting characters identical to the preset delimiters, leading to subsequent parsing misalignment, the business server first constructs a sequential sequence of data to be concatenated based on the position index. After rigorous data cleaning operations such as null value filling and conflict escaping, the final string concatenation is performed, generating a structured link tracing identifier with clear business semantics and a strict correspondence between the position of each level and the order of the field set. Specifically, this may include the following steps: Based on the location index sequence in the business parsing rules, the variable values ​​of the corresponding dimensions are extracted sequentially from the business dimension data to construct a data sequence to be spliced ​​containing the order of events. The location index sequence is used to define the tracking dimensions of each link. Detect missing nodes and conflicting node data containing the preset delimiter in the data sequence to be spliced; The empty nodes are filled with default placeholders, and the conflicting characters in the conflicting node data are escaped and replaced to obtain the cleaned standard data sequence. Traverse the standard data sequence, insert the preset separator between two adjacent data units and concatenate the strings to obtain the structured link tracing identifier.

[0053] After obtaining the business dimension data containing complete request context information, the business server, to ensure that the positions of each level of the final generated tracking identifier are fixed and to facilitate subsequent log retrieval by segmenting and parsing at fixed positions, avoiding semantic parsing errors caused by disordered order, extracts the variable values ​​of the corresponding dimensions from the business dimension data sequentially based on the position index sequence in the business parsing rules. The position index sequence is a predefined ordered list of key names in the business parsing rules. Its purpose is to define the absolute order of the tracking dimensions of each link in the final identifier. The principle of the position index sequence is to specify the physical position of each dimension's data in the form of an array or list. The business server searches for and extracts the corresponding variable values ​​one by one from the key-value pair set of the business dimension data according to the order specified by the position index sequence, storing the extracted variable values ​​in an ordered in-memory array, thus constructing a data sequence to be concatenated containing the order. This data sequence to be concatenated is a temporary data set with a strict physical order. Through the extraction and construction operations, the business server ensures that the extracted fragmented data is given a strict physical order, laying the structural foundation for subsequent standardized concatenation. For example, when the location index sequence is defined as ["Tenant ID", "Order Number"], the business server extracts "Tenant_888" and "ORD-20231001" sequentially from the business dimension data to construct the data sequence to be concatenated ["Tenant_888", "ORD-20231001"].

[0054] After constructing the data sequence to be concatenated, considering that in real network requests, some non-mandatory fields may not be sent, resulting in unextracted values, or the extracted variable values ​​may contain characters identical to the preset delimiter, directly concatenating them without processing could lead to misalignment or mismatched field counts in the final string during segmentation. Therefore, the business server detects empty nodes and conflicting nodes containing the preset delimiter in the data sequence to be concatenated. The business server iterates through the data sequence, checking if each node is empty or null, marking empty nodes as empty nodes. Simultaneously, the business server uses a string matching algorithm to check if the data content of each node contains the preset delimiter, marking nodes containing the preset delimiter as conflicting nodes. Empty and conflicting nodes are abnormal data units identified by the business server during the data verification phase. By performing these detection operations, the business server accurately locates abnormal data that may compromise the integrity of the structured link tracing identifier format, providing a clear target for subsequent data cleaning. For example: If the data sequence to be concatenated is ["Tenant_888", null, "ORD|2023"], and the business server detects that the second node is null, it will mark the second node as a missing node; if the business server detects that the third node contains the preset separator "|", it will mark the third node as conflict node data.

[0055] After locating the abnormal data, to repair it, ensure each dimension has a placeholder value, and prevent data content from interfering with the subsequent delimiter-based segmentation mechanism, the business server fills empty nodes with default placeholders and escapes conflicting characters in conflicting node data. Default placeholders are system-preset special characters without business semantics. Their purpose is to occupy the physical position of missing fields, ensuring that the indices at each level do not shift when the concatenated string is segmented by the delimiter. Escape replacement refers to calling a string replacement function to replace conflicting characters with safe equivalent characters or perform Uniform Resource Locator (URI) encoding. The business server replaces empty nodes with default placeholders and escapes conflicting characters in conflicting node data, resulting in a cleaned standard data sequence. The standard data sequence is an ordered array that fully conforms to the concatenation specifications. By performing filling and escaping operations, the business server completely eliminates the risk of format corruption caused by missing data and character conflicts, ensuring the absolute structure and parsability of the final tracking identifier. For example, the business server fills empty nodes with null with the default placeholder "-", and escapes the "|" in the conflict node data "ORD|2023" as "%7C", resulting in the cleaned standard data sequence ["Tenant_888", "-", "ORD%7C2023"].

[0056] After data cleaning, to transform the cleaned discrete data sequence into a single-line string that can be directly written into the log diagnostic context, the business server traverses the standard data sequence, inserts a preset delimiter between adjacent data units, and concatenates the strings. The preset delimiter is a globally unified special symbol used by the system to serve as the physical boundary between data from different business dimensions. Its principle is to achieve lossless string segmentation using the uniqueness of this special symbol. The business server calls the string concatenation function of the underlying programming language to join the data units after inserting the preset delimiter into a complete long string, obtaining the structured tracing identifier. The structured tracing identifier is a highly condensed and rigorously formatted carrier of business semantics. By performing the string concatenation operation, the business server successfully solidifies multi-dimensional business characteristics into a unified string format, enabling the log retrieval end to quickly reconstruct the complete business context of concurrent requests through simple string splitting operations. For example: The business server traverses the standard data sequence ["Tenant_888", "-", "ORD%7C2023"], inserts the preset separator "|" between adjacent data units, concatenates the strings, and finally obtains the structured link tracing identifier "Tenant_888|-|ORD%7C2023".

[0057] In another specific business scenario, the business dimension data can be flexibly expanded according to actual business needs. This includes, in sequence, the channel number assigned by the system, the business information type determined by the request interface, the business order number submitted by the access party, the transaction device number, and personnel information. The business server combines these dimension data in an ordered manner using preset separators (e.g., underscores "_"), ultimately generating a structured link tracing identifier such as "123456_001_87654321_003_100". This highly customized identifier not only contains rich business semantics but also has strong extensibility, allowing for flexible addition of tracing dimensions according to actual project needs.

[0058] S104. The structured link tracing identifier is written as a custom variable into the log diagnostic context of the thread currently processing the concurrent request to obtain a tracing context environment bound to the concurrent request. The tracing context environment is used to isolate the current request tracing state in a concurrent environment. In concurrent environments, business servers typically use thread pools to handle requests. The same physical thread can be repeatedly reused by multiple different network requests. Without strict state isolation, this can easily lead to distorted log output, making it impossible for developers to accurately trace the complete execution chain of a single request. Therefore, the business server must write the structured tracing identifier as a custom variable into the log diagnostic context of the thread currently handling concurrent requests. This includes the following steps: Identify the application-level thread currently executing the concurrent request and invoke the mapping diagnostic context component of the system's underlying log processing framework; Based on a preset thread-local storage mechanism, the reused historical context cache data in the application-level thread is cleared, and an isolation copy of the variable is initialized for the concurrent request; The structured link tracing identifier is mapped and bound to the feature key name pre-registered in the log processing framework to generate tracing key-value pairs; The tracking key-value pairs are written to the variable isolation copy to obtain the tracking context environment.

[0059] To accurately inject the generated structured tracing identifier into the correct execution environment, the business server identifies the application-level thread currently executing concurrent requests and invokes the mapping diagnostic context component of the system's underlying log processing framework. In a multi-threaded concurrent architecture, network request reception and business logic processing are typically handled asynchronously by different thread pools. If the physical thread currently processing concurrent requests is not accurately identified, the tracing identifier will be incorrectly written to the context of other unrelated threads. Application-level threads originate from the user-space mapping of operating system kernel threads. Their purpose is to serve as independent scheduling units for executing specific business logic code. The principle of application-level threads is to allocate independent program counters and stack space to achieve concurrent instruction execution. The mapping diagnostic context component originates from mainstream log processing frameworks. Its purpose is to provide a thread-bound key-value pair storage mechanism. The principle of the mapping diagnostic context component is to leverage the thread-local characteristics of the underlying programming language to achieve intra-thread data sharing and inter-thread isolation. The business server accurately locates the application-level thread by obtaining the thread identifier of the current execution context and uses the thread identifier to activate the application programming interface of the mapping diagnostic context component. By performing the above operations, the business server successfully established a communication bridge between the business logic execution unit and the underlying logging framework, preparing the basic environment for subsequent tracing identifier injection. For example, when a concurrent request is assigned to an application-level thread named "http-nio-8080-exec-1", the business server obtains the identifier of the application-level thread and calls the mapping diagnostic context component interface of the underlying logging framework to prepare for operations on the application-level thread's logging context.

[0060] After successfully invoking the mapping diagnostic context component, considering that modern business servers commonly use thread pool technology to improve concurrency processing capabilities, application-level threads are not destroyed after processing historical requests but are reused repeatedly. If cleanup is not performed, the trace markers left by historical requests will pollute the logs of current concurrent requests. Therefore, the business server, based on a preset thread-local storage mechanism, clears the reused historical context cache data in the application-level threads and initializes isolated copies of variables for concurrent requests. The preset thread-local storage mechanism comes from the basic concurrency library of the programming language. Its purpose is to provide each thread with an independent copy of variables. The principle of the preset thread-local storage mechanism is to maintain a hash mapping table inside each thread object, so that access to the same variable by different threads does not interfere with each other. Reused historical context cache data refers to the old key-value pairs left in the hash mapping table when the application-level thread processes historical requests. The business server calls the cleanup interface of the mapping diagnostic context component to forcibly clear all residual data in the hash mapping table inside the current application-level thread, completely eliminating the reused historical context cache data. After cleanup, the business server reallocates a clean hash table space in memory for the current concurrent requests, thereby initializing the variable isolation copy. The variable isolation copy is a memory container dedicated to the lifecycle of the current concurrent request. By performing cleanup and initialization operations, the business server completely breaks the chain of context pollution caused by thread reuse, ensuring that the current concurrent requests have an absolutely clean and isolated logging environment. For example, the business server calls the cleanup interface to completely erase the residual historical request tracking identifier "Tenant_111|-|ORD-999" in the "http-nio-8080-exec-1" thread and creates an empty variable isolation copy for the current concurrent request.

[0061] After preparing a clean, isolated copy of the variable, to enable the underlying log processing framework to recognize and extract the structured tracing identifier, the business server maps and binds the structured tracing identifier to a feature key name pre-registered in the log processing framework, generating tracing key-value pairs. When outputting logs, the log processing framework looks up the corresponding value in the context based on pre-configured placeholders. If no explicit key name is specified, the log processing framework will not be able to locate the newly generated structured tracing identifier. The feature key name is a global constant string declared by developers in the log configuration file during system initialization. The purpose of the feature key name is to serve as a unique index for the log processing framework to extract the tracing identifier; in principle, the feature key name acts as a key in a hash mapping table. The business server uses the generated structured tracing identifier as the value and the feature key name as the key to construct a standard key-value pair structure in memory, thereby generating tracing key-value pairs. Tracing key-value pairs are data units that conform to the storage specifications of the mapping diagnostic context component. By performing a mapping and binding operation, the business server assigns the structured trace identifier a legitimate identity that can be automatically recognized by the log processing framework, breaking down the barrier between business code and the underlying log output format. For example, the business server binds the pre-registered feature key name "biz_trace_id" to the structured trace identifier "Tenant_888|-|ORD%7C2023", generating a trace key-value pair <"biz_trace_id","Tenant_888|-|ORD%7C2023">.

[0062] After generating the tracking key-value pairs, to ensure their continued effectiveness throughout the entire processing lifecycle of the current concurrent request, the business server writes them to a variable-isolated copy, thus obtaining the tracking context. The business server calls the write interface of the mapping diagnostic context component to formally store the generated tracking key-value pairs into the application-level thread-specific variable-isolated copy. Once the write is complete, the variable-isolated copy containing the tracking key-value pairs constitutes the complete tracking context. The tracking context is an in-memory data space built by the business server to maintain state consistency throughout the request's lifecycle. Its purpose is to securely store and transparently transmit the unique tracking identifier for the current concurrent request. The principle behind the tracking context is to achieve cross-method parameterless data sharing based on thread-local variables. By performing the write operation, the business server completely isolates the tracking state of the current request in a complex concurrent environment. When the current application-level thread executes any business logic and triggers log printing, the underlying logging framework automatically extracts the tracking key-value pairs from the tracking context and seamlessly appends them to the log text. This ensures that all log records from the same concurrent request carry a unified and accurate business tracking identifier. For example, when the business server calls the write interface and writes the tracking key-value pairs to a variable isolation copy, every line of log printed by the application-level thread thereafter will automatically include the identifier "Tenant_888|-|ORD%7C2023", forming a complete tracking context.

[0063] S105. In response to the business log output instruction, extract the structured link tracing identifier from the tracing context environment, and concatenate the structured link tracing identifier with the log text corresponding to the business log output instruction according to a preset layout pattern to obtain a link tracing log record containing business semantics. After successfully building and isolating the tracing context, when concurrent requests are routed to various business nodes for processing, the business system will inevitably execute various business logics and trigger corresponding log printing operations, thereby generating business log output instructions. To give the originally isolated and context-unrelated regular log text a globally traceable business identity, the business server responds to the business log output instructions by executing step S105. The business server extracts the pre-stored structured tracing identifier from the tracing context and organically concatenates the structured tracing identifier with the log text corresponding to the business log output instructions according to a preset layout pattern, ultimately obtaining a tracing log record containing business semantics. To achieve automated and uniformly formatted log concatenation without intruding on existing business code, the business server needs to delve into the rendering process of the underlying log processing framework. By intercepting underlying log events and waking up specific formatting components, combined with pre-configured log output templates and custom conversion rule nodes, the extracted structured tracing identifier and the original log text are filled into the corresponding placeholders, thus completing the standardized data segment concatenation. This may include the following steps: Intercept the log events generated by the business log output command and wake up the formatting component of the underlying log processing framework of the system; The structured link tracing identifier is dynamically retrieved from the tracing context by using a custom transformation rule node pre-configured in the formatting component. Load the log output template corresponding to the preset layout mode. The log output template includes native placeholders for carrying the original log content and custom placeholders for declaring extended tracking dimensions. The log text is filled into the corresponding native placeholder to obtain the business content data segment, and the structured link tracing identifier is filled into the corresponding custom placeholder to obtain the tracing identifier data segment; According to the placeholder arrangement order in the log output template, the tracking identifier data segment and the business content data segment are concatenated to obtain the link tracing log record.

[0064] During the processing of concurrent requests, business nodes inevitably execute business logic and call printing code. To automatically inject the isolated tracing identifiers into the regular logs without intruding on or modifying the original business code, the business server intercepts the log events generated by the business log output commands and wakes up the formatting component of the underlying log processing framework. When the business code calls the log printing method, it merely issues a command containing raw text. The business server uses aspect-oriented programming or the built-in filter mechanism of the logging framework to intercept the command before it is actually output to the console or file. Log events originate from the memory encapsulation of the logging framework at runtime. The purpose of log events is to carry basic runtime information such as raw log text, log level, and timestamp. The principle of log events is that they are data objects instantiated the moment the business code calls the print method. The formatting component originates from the core rendering engine of the logging processing framework. The purpose of the formatting component is to transform the log event objects in memory into the final output string that meets the formatting requirements. The principle of the formatting component is to parse and replace characters based on a preset pattern. By performing interception and wake-up operations, the business server successfully takes over the output control flow of regular logs, creating operational space for subsequent injection of tracing identifiers. For example, when the business code executes "log.info("Order created successfully")", the business server intercepts the resulting log event, pauses the direct output of the log, and wakes up the formatting component of the underlying log processing framework to prepare for deep rendering.

[0065] After waking the formatting component, to accurately extract the tracing identifiers stored in the thread context into the current log rendering process, the business server uses custom transformation rule nodes pre-configured in the formatting component to dynamically call back and extract the structured tracing identifiers from the tracing context. The standard logging framework does not have the ability to read custom business contexts by default, so the business server must rely on an extension mechanism. Custom transformation rule nodes originate from the log processing framework's plugin extension system. Their purpose is to act as a bridge between the log rendering engine and external custom data sources. The principle of custom transformation rule nodes is to define exclusive string extraction logic by implementing specific transformation interfaces. Dynamic callbacks originate from the Inversion of Control (IoC) design pattern in object-oriented programming. Their purpose is to trigger developer-defined retrieval logic on demand within the framework's standard execution flow. The principle of dynamic callbacks is to use delayed binding and execution of interface implementation classes. The business server uses custom transformation rule nodes to trigger dynamic callback functions, accurately reading isolated copies of variables bound to the current thread, thereby extracting the structured tracing identifiers. By performing the extraction operation, the business server successfully pulls the tracing data hidden deep within the underlying layers to the surface preparation area for log rendering. For example, when the formatting component executes a custom transformation rule node during the rendering process, it triggers a dynamic callback and successfully extracts the structured tracing identifier "Tenant_888|-|ORD%7C2023" from the current thread's tracing context.

[0066] After extracting the structured tracing identifiers, to ensure a consistent log text format in the final output and facilitate automated segmentation and parsing by the log retrieval end based on fixed positions, the business server loads a log output template corresponding to the preset layout pattern. The log output template originates from an external configuration file loaded during system initialization. Its purpose is to serve as a globally unified log formatting blueprint, and it works by containing formatted strings with specific syntax markers. The log output template includes native placeholders for carrying the original log content and custom placeholders for declaring extended tracing dimensions. Native placeholders originate from the default transformation configuration built into the log processing framework. Their purpose is to reserve physical space in log lines for timestamps, thread names, and original business text. They work by using fixed escape syntax, such as a percent sign followed by a specific letter. Custom placeholders originate from format declarations added by developers to meet tracing requirements. They are specifically designed to specify the output position for the structured tracing identifiers, and they work by mapping names to the aforementioned custom transformation rule nodes. By loading log output templates, the business server establishes a strict structural framework for log concatenation. For example, in practical applications, if the underlying log processing framework uses Logback, the business server can configure the `conversionRule` node in the Logback configuration file to implement the aforementioned custom conversion rule node, and add this structured trace identifier to the log using a custom `log.pattern` (i.e., the log output template). For instance, the business server loads the log output template "[%d{yyyy-MM-ddHH:mm:ss}][%thread][%custom_trace_id]-%msg", where "%msg" is the native placeholder and "%custom_trace_id" is a custom placeholder mapped through `conversionRule`, thus achieving coexistence and expansion with the original log content.

[0067] After establishing the log concatenation framework, the business server enters the substantive data rendering phase. It fills the log text into the corresponding native placeholders to obtain the business content data segment, and fills the structured tracing identifiers into the corresponding custom placeholders to obtain the tracing identifier data segment. The business server calls the character replacement engine within the formatting component to precisely align the intercepted raw log text and write it into the memory area where the native placeholders reside, forming the business content data segment. The business content data segment originates from the output intent of the original business code. Its purpose is to preserve the actual state description during the execution of business nodes; the principle of the business content data segment is a plain text string that has undergone escape processing. Simultaneously, the business server writes the extracted structured tracing identifiers into the memory area where the custom placeholders reside, forming the tracing identifier data segment. The tracing identifier data segment originates from the tracing context. Its purpose is to assign a globally unique business identity to the current log line; the principle of the tracing identifier data segment is a formatted string containing multi-dimensional business characteristics. Through the filling operation, the business server transforms the abstract template placeholders into concrete string fragments containing actual runtime data. For example: The business server fills the log text "Order created successfully" into "%msg" to obtain the business content data segment, and fills "Tenant_888|-|ORD%7C2023" into "%custom_trace_id" to obtain the tracking identifier data segment.

[0068] After completing the visualization and filling of each data segment, in order to generate a complete text line that can be persistently stored and sent to the log retrieval end, the business server concatenates the tracing identifier data segment and the business content data segment according to the placeholder arrangement order in the log output template, resulting in a tracing log record. Relying on the underlying character buffer stream, the business server strictly follows the preset physical order of the log output template, sequentially connecting the regular data segment containing time and thread information, the tracing identifier data segment, and the business content data segment, eliminating segment gaps in memory. The tracing log record originates from the final product of the log rendering process. Its purpose is to serve as complete evidence of the execution trajectory of concurrent requests at the current business node. The principle of tracing log recording is to append a continuous byte sequence with newline characters. Through the concatenation operation, the business server achieves seamless integration of the original business log and the underlying tracing identifier, instantly giving the originally isolated log text a global business perspective for tracing, providing a perfect structured data source for efficient data location by the subsequent log retrieval end. For example: The business server concatenates the data according to the template order, and finally generates the tracing log record "[2023-10-01 12:00:00] [http-nio-8080-exec-1][Tenant_888|-|ORD%7C2023]-Order creation successful", and prepares to send the tracing log record to the log retrieval terminal.

[0069] S106. The link tracing log record is sent to the log retrieval terminal so that the log retrieval terminal responds to the log retrieval request and locates the data in the link tracing log record based on the structured link tracing identifier to obtain the log link tracing result.

[0070] After the business server completes the concatenation of log text and generates the tracing log record in local memory, in order to break the physical isolation of logs between various business nodes in the distributed high-concurrency architecture and prevent log data from becoming isolated information islands that cannot be globally correlated, the business server sends the tracing log record to the log retrieval end. The business server calls the asynchronous log collection proxy component to continuously push the tracing log record to the log retrieval end in the form of a data stream via network transmission protocol. The log retrieval end originates from the centralized log management platform in the distributed system architecture. The purpose of the log retrieval end is to provide unified storage, full-text indexing, and visual query services for massive log data. The principle of the log retrieval end is to achieve efficient text aggregation and retrieval based on the inverted index engine and distributed file system.

[0071] By executing the send operation, the business server successfully aggregated the local operational statuses scattered across various physical machines into a unified global data center. When system maintenance personnel or developers need to troubleshoot execution anomalies in specific business requests, they can input query conditions containing specific business dimensions through the front-end console, thereby triggering a log retrieval request. The log retrieval request originates from query commands initiated during online fault investigation. Its purpose is to transmit specific query conditions to the log retrieval end. The principle behind the log retrieval request is to send data packets containing query keywords to the application programming interface exposed by the log retrieval end via the Hypertext Transfer Protocol (HTTP). In response to the log retrieval request, the log retrieval end activates its internal search engine, locating data based on structured link tracing identifiers within massive amounts of link tracing log records. Because structured link tracing identifiers are generated strictly according to preset delimiters and fixed hierarchical positions, the built-in word segmenter in the log retrieval end can extremely accurately segment structured link tracing identifiers into independent index terms, thus avoiding the large number of false positives and performance losses caused by traditional fuzzy matching.

[0072] The log retrieval end uses an inverted index mechanism to instantly filter out all log lines containing the target structured tracing identifier, and then strictly sorts the filtered log lines according to their timestamps, ultimately obtaining the log tracing result. The log tracing result originates from a dataset after the log retrieval end has filtered and aggregated massive amounts of logs. The purpose of the log tracing result is to visually display the complete lifecycle and execution trajectory of a single concurrent request within the entire distributed system. The principle behind the log tracing result is to sort and assemble log lines that match the same structured tracing identifier according to their timestamps.

[0073] By performing the above retrieval and location operations, the system achieves seamless drill-down from macro-level business metrics to micro-level code execution details, greatly improving troubleshooting efficiency in complex concurrent environments. For example, the business server sends a tracing log record containing "Tenant_888|-|ORD%7C2023" to the log retrieval end. When developers initiate a log retrieval request containing "ORD%7C2023" to investigate the cause of order creation failure, the log retrieval end performs precise data location based on this structured tracing identifier "Tenant_888|-|ORD%7C2023," instantly extracting all relevant logs printed when the concurrent request passes through the gateway node, order node, and payment node. The relevant logs are then arranged in chronological order, generating a complete log tracing result for developers to analyze.

[0074] Furthermore, because the generated structured link tracing identifiers are assigned specific business meanings (such as including channel number, business type, equipment and personnel information), the log retrieval terminal, after receiving and parsing these logs, can not only use them for precise fault diagnosis but also conveniently perform business information statistics across various dimensions. For example, operations personnel can directly use these structured identifiers to statistically analyze transaction volume for a specific channel, a specific business type, or a specific business type within a specific channel. This greatly enriches the statistical dimensions and application value of log data, enabling a leap from simple operations and maintenance monitoring to business operations analysis.

[0075] Please see Figure 3 This is a schematic diagram of the structure of a log tracing system for concurrent requests in an embodiment of this application.

[0076] It should be noted that, Figure 3 The structure of a concurrent request log tracing system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0077] like Figure 3 As shown, a concurrent request log tracing system includes a central processing unit 301, which can perform various appropriate actions and processes based on a program stored in a read-only memory 302 or a program loaded from a storage section 308 into a random access memory 303, such as performing the methods described in the above embodiments. The random access memory 303 also stores various programs and data required for system operation. The central processing unit 301, the read-only memory 302, and the random access memory 303 are interconnected via a bus 304. An input / output interface 305 is also connected to the bus 304.

[0078] The following components are connected to the input / output interface 305: an input section 306 including audio input devices, push-button switches, etc.; an output section 307 including an LCD display, audio output devices, indicator lights, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to the input / output interface 305 as needed. A removable medium 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 310 as needed so that computer programs read from it can be installed into the storage section 308 as needed.

[0079] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit 301, it performs the various functions defined in the present invention.

[0080] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, flash memory, optical fiber, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0081] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0082] Specifically, a concurrent request log tracing system according to this embodiment includes a processor and a memory. The memory stores a computer program, and when the computer program is executed by the processor, it implements a concurrent request log tracing method provided in the above embodiment.

[0083] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in a concurrent request log tracing system described in the above embodiments; or it may exist independently and not assembled into the concurrent request log tracing system. The storage medium carries one or more computer programs that, when executed by a processor of the concurrent request log tracing system, cause the concurrent request log tracing system to implement the concurrent request log tracing method provided in the above embodiments.

Claims

1. A method for log tracing of concurrent requests, characterized in that, Applied to the business server, the method includes: In response to concurrent requests, based on the request header features and routing address of the concurrent requests, a business parsing rule corresponding to the concurrent request is matched from a preset rule base. The business parsing rule defines the set of fields and extraction paths for the link tracing dimensions to be extracted for different business scenarios. Based on the extraction path, the corresponding business dimension data is dynamically parsed from the request messages of the concurrent requests; According to the hierarchical splicing order defined in the business parsing rules, the business dimension data is combined in an orderly manner through preset delimiters to generate a structured link tracing identifier with business semantics. The position of each level of the structured link tracing identifier corresponds to the order of the field set. The structured link tracing identifier is written as a custom variable into the log diagnostic context of the thread currently processing the concurrent request, thereby obtaining a tracing context environment bound to the concurrent request. The tracing context environment is used to isolate the current request tracing state in a concurrent environment. In response to the business log output instruction, the structured link tracing identifier is extracted from the tracing context environment, and the structured link tracing identifier is concatenated with the log text corresponding to the business log output instruction according to a preset layout pattern to obtain a link tracing log record containing business semantics; The link tracing log records are sent to the log retrieval terminal, so that the log retrieval terminal responds to the log retrieval request, locates the data in the link tracing log records based on the structured link tracing identifier, and obtains the log link tracing result.

2. The method according to claim 1, characterized in that, The step of dynamically parsing the corresponding business dimension data from the request messages of the concurrent requests based on the extraction path specifically includes: Based on the extraction path in the business parsing rules, the field set is divided into a first type of field located in the header area of ​​the request message and a second type of field located in the payload area of ​​the request message. Parse the environmental dimension data corresponding to the first type of field from the header region; When the data volume of the load area is greater than the preset memory safety threshold, a streaming read cursor with a state tracking task is bound to the data stream of the load area. The state tracking task contains all the node paths to be matched corresponding to the second type of field. Based on the state tracking task, the streaming read cursor is driven to intercept and scan the data stream to obtain the corresponding target features; When the data volume of the load region is less than or equal to the preset memory safety threshold, the load region is fully parsed based on the addressing expression corresponding to the second type of field to obtain the corresponding target feature; The environmental dimension data is assembled with the target features to obtain the business dimension data.

3. The method according to claim 2, characterized in that, The step of using the state tracking task to drive the streaming cursor to intercept and scan the data stream to obtain corresponding target features specifically includes: The streaming cursor is driven to scan the data stream step by step downwards. When the current node path scanned is consistent with the target path, the current node path is determined as the matching path. The node data content corresponding to the matching path is extracted as the target feature, and the target path corresponding to the matching path is deregistered from the state tracking task. The target path is any path among the node paths to be matched. When all the matching node paths in the state tracking task have been cancelled, in response to the full load interruption mechanism, a safe short-circuit instruction is triggered to terminate the scanning of the remaining unread content of the data stream by the streaming read cursor.

4. The method according to claim 2, characterized in that, The step of performing full memory parsing of the load region based on the addressing expression corresponding to the second type of field to obtain the corresponding target feature specifically includes: Based on the addressing expression corresponding to the second type of field, the payload region of the request message is converted into a memory node tree; The memory node tree is traversed and matched to extract the service carrier identifier sent by the access party. The business carrier identifier is converted into a string format to obtain the target feature.

5. The method according to claim 1, characterized in that, The step of combining the business dimension data in an orderly manner using preset delimiters according to the hierarchical concatenation order defined in the business parsing rules to generate a structured link tracing identifier with business semantics specifically includes: Based on the location index sequence in the business parsing rules, the variable values ​​of the corresponding dimensions are extracted sequentially from the business dimension data to construct a data sequence to be spliced ​​containing the order of events. The location index sequence is used to define the tracking dimensions of each link. Detect missing nodes and conflicting node data containing the preset delimiter in the data sequence to be spliced; The empty nodes are filled with default placeholders, and the conflicting characters in the conflicting node data are escaped and replaced to obtain the cleaned standard data sequence. Traverse the standard data sequence, insert the preset separator between two adjacent data units and concatenate the strings to obtain the structured link tracing identifier.

6. The method according to claim 1, characterized in that, The step of writing the structured link tracing identifier as a custom variable into the log diagnostic context of the thread currently processing the concurrent request to obtain a tracing context environment bound to the concurrent request specifically includes: Identify the application-level thread currently executing the concurrent request and invoke the mapping diagnostic context component of the system's underlying log processing framework; Based on a preset thread-local storage mechanism, the reused historical context cache data in the application-level thread is cleared, and an isolation copy of the variable is initialized for the concurrent request; The structured link tracing identifier is mapped and bound to the feature key name pre-registered in the log processing framework to generate tracing key-value pairs; The tracking key-value pairs are written to the variable isolation copy to obtain the tracking context environment.

7. The method according to claim 1, characterized in that, The step of concatenating the structured link tracing identifier with the log text corresponding to the business log output instruction according to a preset layout pattern to obtain a link tracing log record containing business semantics specifically includes: Intercept the log events generated by the business log output command and wake up the formatting component of the underlying log processing framework of the system; The structured link tracing identifier is dynamically retrieved from the tracing context by using a custom transformation rule node pre-configured in the formatting component. Load the log output template corresponding to the preset layout mode. The log output template includes native placeholders for carrying the original log content and custom placeholders for declaring extended tracking dimensions. The log text is filled into the corresponding native placeholder to obtain the business content data segment, and the structured link tracing identifier is filled into the corresponding custom placeholder to obtain the tracing identifier data segment; According to the placeholder arrangement order in the log output template, the tracking identifier data segment and the business content data segment are concatenated to obtain the link tracing log record.

8. A log tracing system for concurrent requests, characterized in that, The concurrent request log tracing system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors invoke the computer instructions to cause the concurrent request log tracing system to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on a concurrent request log tracing system, it causes the concurrent request log tracing system to perform the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on a concurrent request log tracing system, the concurrent request log tracing system performs the method as described in any one of claims 1-7.

Images