Link identification-based service log storage method, system, device and storage medium

Abstract

The application provides a link identification-based service log storage method, system, device and storage medium, the method comprising: determining a global link identification for a service operation, so that the front-end behavior, system interface and service processing three types of logs carry the same identification value; writing the service log into a columnar storage database in a mixed mode of a fixed-length field and a variable-length array, the fixed-length field at least containing the global link identification and a timestamp, the variable-length array containing an equal-length key set and a value set corresponding to the key set by subscript; when a new service index is added, only the key-value pair is added to the array, without performing table structure change; when inquiring, taking the global link identification as an anchor point to associate three types of data sources to restore a complete execution path, and through the subscript positioning mode, the key-value array is screened and aggregated, and anchor point jumping, in-page drilling and index linkage display are provided. The application realizes unified association of three types of logs, DDL-free expansion of service indexes and linkage insight of logs and indexes.

Description

Technical Field

[0001] This invention relates to the field of log processing technology, and more specifically, to a method, system, device, and storage medium for storing business logs based on link identifiers. Background Technology

[0002] In a microservice architecture, a single business operation (such as a ticket change, a ticket refund, or an order placement) often spans the front-end page, multiple internal services, middleware, and the database. A single operation may generate the following three types of logs: Front-end user behavior logs: Record user actions on the client side, including page views (PageView), click events, and API initiation times. Typical scenario: A user clicks the "Confirm Rescheduling" button in the app, triggering a front-end behavior log entry.

[0003] System API call logs: Record SOA / HTTP API calls between backend services, including request parameters, response results, and execution time. Typical scenario: The rescheduling service calls the issueTicket API of the ticketing service.

[0004] Business processing logs: Record the processing results and status transitions at the business semantic level, including order status changes, risk control judgment results, inventory deduction results, and reasons for failure. Typical scenario: "Seat locking failed in the rebooking process, reason = insufficient inventory".

[0005] To locate problems in such business operations, existing technologies typically employ the following methods: Application log direct storage and query: Each application collects and stores logs in a log database (such as a columnar storage database). Queries specify the application identifier (appId) and time range for retrieval. Typically, a distributed tracing system is used to generate a call chain identifier (such as traceId) for each call, and the interface call logs under the same request are associated according to the call chain identifier.

[0006] Business logs with fixed table structure: Business users write business logs to the log database according to predefined fixed fields (columns), such as defining columns such as order_status, fail_reason, and channel. Each business metric corresponds to a fixed column in the table.

[0007] Independent indicator dashboards: A separate indicator system is built using open-source visualization dashboard tools to visualize some aggregated indicators. The dashboard data source and log library are independent of each other.

[0008] The existing technology has the following objective defects: Defect 1 (Scattered Business Logs, Lack of a Unified Anchor Point): Business semantic logs are scattered across various business applications and have inconsistent formats. Existing trace IDs (traceId) are only generated and transmitted at the system / interface call layer, not reaching the business logs and front-end behavior logs. Therefore, it is impossible to associate the three types of logs—front-end behavior logs, system interface logs, and business processing logs—with a single anchor point to the same business operation. This results in the need to log into multiple systems separately for comparison when troubleshooting, making it difficult to reconstruct the complete context of a single business operation.

[0009] Defect 2 (fixed table structure, high expansion cost): When adding new business indicator fields (such as adding the "member level" dimension), the business log with a fixed column structure must perform a table structure change (DDL), which involves cross-team coordination (DBA approval, test regression) and a long deployment cycle (days), making it difficult to adapt to rapid changes in business indicators (weekly iterations).

[0010] Defect 3 (Separation of Three Sources and Separation of Queries): Existing queries can only retrieve a certain type of log by a single application identifier and time range. Front-end behavior, system interface, and business processing logs are stored in different databases / tables without a unified association key. Users cannot see the complete execution path and status flow of "what the user did on the front end → which interfaces were called → what the business processing result was" in a single query.

[0011] Defect 4 (Separation of logs and metrics, lack of interconnected insights): The dashboard and specific business logs are independent of each other. When a user views a business log (e.g., "Rescheduling failed, reason = insufficient inventory"), the trend distribution of the "insufficient inventory" dimension within the same time window cannot be displayed immediately. "Viewing logs" and "viewing metrics" are two separate operations. From discovering an anomaly to determining whether it is a systemic problem, multiple jumps and manual correlation are required, which is inefficient.

[0012] The fundamental reason for the above defects is that the existing technology lacks an integrated "storage-association-visualization" mechanism that can connect logs from three different sources with a unified anchor point, flexibly expand business indicator fields without changing the table structure, and link the trend of a single log with the indicator of its respective dimension.

[0013] In view of this, the present invention provides a method, system, device and storage medium for storing business logs based on link identifiers. Summary of the Invention

[0014] To address the problems in existing technologies, the present invention aims to provide a business log storage method, system, device, and storage medium based on link identifiers. This overcomes the difficulties of existing technologies and enables the front-end behavior, interface calls, and business processing logs of a single business operation to be associated with a unified anchor point to restore the complete context. Business indicator fields can be flexibly expanded without modifying the table structure (DDL). The indicator trends of a single log and its corresponding dimension can be presented in a linked manner within the same view. This improves the efficiency of problem localization from "hourly system-by-system investigation" to "minute-level one-screen localization".

[0015] Embodiments of the present invention provide a service log storage method based on link identifiers, comprising the following steps: S110. Determine a global link identifier for a business operation. The global link identifier is consistent across the front-end behavior log, system interface log, and business processing log of the business operation, and is written to the columnar storage database along with the business log as a unique anchor point for cross-three-source association. S120. Write the business logs into the columnar storage database in a mixed mode of fixed-length fields and variable-length arrays. The fixed-length fields include at least a global link identifier and a timestamp. The variable-length arrays include at least a first key set and a first value set, a second key set and a second value set. The key set and value set in the same group are of equal length and correspond one-to-one with the index. S130. When it is necessary to add a new business indicator field, the table structure change operation is not performed. Instead, when writing to the business log, the key name is appended to the second key set and the corresponding value is appended to the second value set at the same index position. When querying, the new field can be used for filtering, grouping, aggregation and statistics. S140. When querying, use the global link identifier as the anchor point to retrieve records carrying the identifier from the front-end behavior log data source, system interface log data source, and business processing log data source respectively. Sort and merge the three types of logs by timestamp to restore the complete execution path of the business operation. S150. When performing key-value filtering or group aggregation statistics on the business logs obtained by global link identifier retrieval in step S140, first locate the index position of the target key in the corresponding key set, then perform value query from the corresponding value set according to the index to obtain the value result, and perform filtering or group aggregation statistics based on the obtained value. S160. Based on the related query results, provide anchor jump, drill-down within the page and linked display of indicators.

[0016] Preferably, step S110 includes: S111. After the global link identifier is generated at the interface layer, it is transmitted to the downstream of the business processing link through the thread context or request context to ensure that all processing links of the same business operation obtain the same identifier value. S112. Front-end behavior logs are collected through a front-end event tracking system. The front-end event tracking system obtains the global link identifier from the server-side interface response and carries it in the front-end behavior logs. S113. System interface logs are collected non-intrusively using a bytecode enhancement probe. When the probe intercepts the system interface entry and exit, it extracts the global link identifier in the current thread context and writes it into the interface log. S114. The business processing log is output by the business application actively calling the log client. The log client obtains the global link identifier from the current thread context and writes it into the business log.

[0017] Preferably, in step S120: the fixed-length field further includes at least one of order number, user identifier, and device identifier as a business association auxiliary field; the first key set carries the key name of the common dimension, and the first value set carries the common dimension value with the same length as the first key set and corresponding to the index one-to-one; the second key set carries the key name of the business indicator, and the second value set carries the business indicator value with the same length as the second key set and corresponding to the index one-to-one; the fixed-length field is determined when the table is created and serves as the direct index field during querying, and the variable-length array is stored using the native array type of the columnar storage database; A data format conversion step is included before step S120: S121. Rename the fields with naming prefixes passed by the upstream message middleware to restore their original field names; S122. The four array fields, namely the first key set, the first value set, the second key set, and the second value set, are deserialized from the string form during the transmission stage into array type and then stored. The business logs are written to the columnar storage database in an asynchronous batch writing mode, and the main business thread is not blocked or waits for the writing to be completed.

[0018] Preferably, in step S140, when the query entry only provides a gateway tracing identifier instead of a global link identifier, a gateway identifier conversion step is also included: S141. Query the record corresponding to the gateway tracking identifier from the system interface log. If the corresponding record is found, obtain the tag key array and tag value array of the record. If it is not found, prompt that the gateway tracking identifier is invalid. S142. Verify that the tag key array and the tag value array are of equal length; S143. Locate the target key in the tag key array using the index positioning method, and retrieve the value of the global link identifier from the tag value array by the index; S144. Use the extracted global link identifier as the anchor point for subsequent three-source association queries; S145. Render the execution path of the business operation into a timeline view in ascending order of timestamps. The timeline includes the following node types: front-end behavior nodes, interface call nodes, data storage access nodes, cache access nodes, and message queue interaction nodes.

[0019] Preferably, in step S150: the subscript value query further includes a time window aggregation step: the timestamps of the business logs are bucketed according to a preset time granularity, and the results of the target key's subscript values ​​in the first key set or the second key set are filtered and statistically grouped by time bucket; a query upper limit is set for each query and the query results are arranged in reverse order by timestamp to control resource consumption; the columnar storage database uses an array subscript positioning function to implement key-value query, wherein the position of the target key in the key set is located by the indexOf function, and the corresponding value is retrieved by the value set [indexOf(key set, target key)].

[0020] Preferably, the anchor point jump in step S160 includes: S161. Preset anchor points on the interface nodes or business log nodes of the timeline; S162. When a user triggers an anchor point, a match is made in the set of business logs associated with the global link identifier based on the business field value conditions or tag key conditions specified by the user. S163. Upon a hit, the system automatically locates the corresponding business log and highlights it. The tag key condition includes two matching modes: the specified tag key exists and the specified tag key equals a specified value. The drill-down within the page includes: after triggering the anchor point, the system expands the list of business logs associated with the current node in the current query context in an asynchronous manner, rather than jumping to an independent page, in order to maintain the continuity of the query context.

[0021] Preferably, the linked display of indicators in step S160 includes: S164. When a user selects a business log, the system parses the keys carried in the variable-length array of that business log as the analysis dimension. S165. Based on the analysis dimension and the current time window, query records of the same dimension from the business log set; S166. Render the query results as a trend chart changing over time and a distribution chart by dimension, so that the aggregate trend and distribution of a single log and its corresponding dimension are presented in the same view.

[0022] Embodiments of the present invention also provide a service log storage system based on link identifiers, used to implement the above-described service log storage method based on link identifiers, wherein the service log storage system based on link identifiers includes: The log collection module is used to determine a global link identifier for a business operation. The global link identifier is consistent across the front-end behavior log, system interface log, and business processing log of the business operation, and is written to the columnar storage database along with the business log as a unique anchor point for cross-three-source association. The structured storage module is used to write business logs into a columnar storage database in a mixed mode of fixed-length fields and variable-length arrays. The fixed-length fields include at least a global link identifier and a timestamp. The variable-length array includes at least a first key set and a first value set, a second key set and a second value set. The key set and value set in the same group are of equal length and correspond one-to-one with the index. The new business module is used to add a new business indicator field without performing a table structure change operation. Instead, it adds the key name to the second key set and the corresponding value to the second value set at the same index position when writing to the business log. The new field can then be used for filtering, grouping, aggregation, and statistics during the query. The related query module is used to retrieve records carrying the global link identifier from the front-end behavior log data source, system interface log data source, and business processing log data source respectively when querying. The three types of logs are sorted by timestamp and merged to restore the complete execution path of the business operation. The aggregation statistics module is used to perform key-value filtering or group aggregation statistics on business logs retrieved by the global link identifier in the related query module. First, it locates the index position of the target key in the corresponding key set, and then performs a value query from the corresponding value set according to the index to obtain the value result. Based on the obtained value, it performs filtering or group aggregation statistics. The linked display module is used to provide anchor jumps, drill-down within the page, and linked display of indicators based on related query results.

[0023] Embodiments of the present invention also provide a service log storage device based on link identifier, comprising: processor; A memory in which executable instructions of the processor are stored; The processor is configured to execute the steps of the above-described link-identifier-based service log storage method by executing the executable instructions.

[0024] Embodiments of the present invention also provide a computer-readable storage medium for storing a program, which, when executed, implements the steps of the above-described link-identifier-based service log storage method.

[0025] The purpose of this invention is to provide a business log storage method, system, device, and storage medium based on link identifiers, which can restore the complete context of a business operation's front-end behavior, interface calls, and business processing logs by associating them with a unified anchor point; business indicator fields can be flexibly expanded without modifying the table structure (DDL); a single log and the indicator trends of its corresponding dimension can be presented in a linked manner within the same view; thereby improving the efficiency of problem localization from "hourly system-by-system investigation" to "minute-level one-screen localization". Attached Figure Description

[0026] Other features, objects, and advantages of the invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0027] Figure 1 This is a flowchart of the service log storage method based on link identifier of the present invention.

[0028] Figure 2 This is a schematic diagram of the overall architecture of the business log storage method based on link identifiers that implements the present invention.

[0029] Figure 3 This is a schematic diagram of the structured storage model of business logs in the business log storage method based on link identifier of the present invention.

[0030] Figure 4 This is a flowchart of the full-link association query process in the business log storage method based on link identifier of the present invention.

[0031] Figure 5 This is a flowchart of the index value query and time window aggregation process in the business log storage method based on link identifier of the present invention.

[0032] Figure 6 This is a flowchart of the data format conversion process in the business log storage method based on link identifier of the present invention.

[0033] Figure 7 This is a schematic diagram of anchor point jump and indicator linkage drill-down in the business log storage method based on link identifier of the present invention.

[0034] Figure 8 This is a system architecture diagram of the business log storage system based on link identification according to the present invention.

[0035] Figure 9 This is a schematic diagram of the business log storage device based on link identification according to the present invention.

[0036] Figure 10 This is a schematic diagram of the structure of a computer-readable storage medium according to an embodiment of the present invention. Detailed Implementation

[0037] The following specific examples illustrate the implementation methods of this application. Those skilled in the art can easily understand the other advantages and effects of this application from the content disclosed herein. This application can also be implemented or applied through other different specific embodiments, and various details in this application can be modified or changed according to different viewpoints and application systems without departing from the spirit of this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be combined with each other.

[0038] The embodiments of this application will now be described in detail with reference to the accompanying drawings, so that those skilled in the art can easily implement the application. This application may be embodied in many different forms and is not limited to the embodiments described herein.

[0039] In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics represented in connection with that embodiment or example, which are included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics represented may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate different embodiments or examples represented in this application, as well as features of different embodiments or examples.

[0040] Figure 1 This is a flowchart of the service log storage method based on link identifier of the present invention. Figure 1As shown, this invention provides a method for structured storage, full-link association, and visual drill-down of business logs based on a global link identifier, including steps S110 to S160. In one embodiment, the method runs on a log processing platform in a distributed microservice environment. In step S110, the system generates a global link identifier (e.g., root_message_id) for a business operation (e.g., a flight ticket rescheduling operation). This identifier remains consistent across the front-end behavior log (recorded when the user clicks the "Confirm Rescheduling" button), the system interface log (recorded when the rescheduling service calls the ticketing service), and the business processing log (rescheduling result record), and is written to the ClickHouse columnar storage database along with the business log. In step S120, the business log is stored in a hybrid mode using fixed-length fields (root_message_id, timestamp, order_number, etc.) and variable-length arrays (common_keys / common_vals, business_keys / business_vals). In step S130, when a new "Member Level" field needs to be added, there is no need to use ALTER TABLE; simply append "level" to business_keys and "Gold" to business_vals during the write operation. In step S140, the query uses root_message_id as the anchor point, retrieving and merging data from three sources—UBT frontend logs, SOA interface logs, and CK business logs—into a timeline. In step S150, the indexOf function is used to locate the target key index and extract values ​​from the corresponding value set for filtering and aggregation. In step S160, anchor point navigation, drill-down within the page, and linked indicator display are provided. The technical advantages of this embodiment are: for the first time, the global link identifier is simultaneously deployed to three types of logs, enabling a single query to restore the complete business context. The variable-length array structure eliminates the need for DDL for field expansion, shortening the expansion cycle from days to immediate effect. The index-based value retrieval method allows for efficient retrieval and aggregation of columnar array fields. Visual drill-down capabilities enable the conversion from logs to metrics to be completed within the same view, improving problem localization efficiency from hours to minutes.

[0041] In a preferred embodiment, step S110 includes: In step S111, after the global link identifier is generated at the gateway layer, it is passed to the entire call chain through the thread context (ThreadLocal) to ensure that all links such as the rescheduling service, ticketing service, and payment service obtain the same root_message_id. In step S112, the front-end event tracking system (UBT SDK) obtains the root_message_id from the header of the server's HTTP response and carries it in the front-end behavior log. In step S113, when the bytecode enhancement probe based on the ByteBuddy framework intercepts the entry and exit points of the SOA interface, it extracts the root_message_id from the current thread context and writes it into the tag array of the interface log. In step S114, when the business application actively calls the logger.info() method through the log client to output business logs, the log client automatically obtains the root_message_id from the thread context and writes it into the log record. The technical advantages of this embodiment are as follows: the thread context passing mechanism ensures that the global link identifier is not lost or confused in the complex distributed call chain; the front-end instrumentation obtains the identifier from the server response, realizing a closed-loop association between the front-end behavior and the back-end call chain; the bytecode enhancement probe realizes zero-intrusion collection, and the business code does not need to be aware of the identifier passing logic; the log client automatically injects the identifier, reducing the cognitive burden and error probability of business developers.

[0042] In a preferred embodiment, in step S120, the fixed-length fields further include order_number (order number), uid (user identifier), and cid (device identifier). These fields are determined during table creation and used as direct index fields for queries. The first key set common_keys carries common dimensions such as ["host","env","service_name"], and the first value set common_vals carries ["10.0.1.1","prod","payment-service"]. The second key set business_keys carries business metrics such as ["status","channel"], and the second value set business_vals carries ["success","alipay"]. The variable-length array is stored using ClickHouse's native Array(String) type. Before step S120, in step S121, the __message field in the Kafka message is renamed to message, __level is renamed to level, and @timestamp is renamed to timestamp. Step S122 deserializes the four array fields, including common_keys, from the JSON string format during transmission into ClickHouse Array type and stores them. Business logs are written asynchronously in batches; the main business thread calls the log client and returns immediately without waiting for ClickHouse write confirmation. The technical advantages of this embodiment are: fixed-length fields as index columns provide efficient filtering capabilities; the key-value pair model of variable-length arrays achieves a balance between structure and flexibility; the field renaming step eliminates field name pollution caused by message middleware, ensuring the semantic clarity of the storage model; array deserialization ensures the correctness of data types, enabling subsequent index value queries to function correctly; and the asynchronous batch writing mechanism ensures zero impact of log collection on the main business process, preventing log writing from becoming a performance bottleneck.

[0043] In a preferred embodiment, in step S140, when the user provides only the gateway trace identifier (gateway_trace_id) instead of the root_message_id, the system performs a gateway identifier conversion step. Step S140 includes: Step S141: Query the system interface log for the record corresponding to the gateway_trace_id. If the record is not found, a message "Gateway trace identifier invalid" is displayed. Step S142: Verify that the tag key array _tag_keys and the tag value array _tag_vals are of equal length. If they are not of equal length, a "Tag data format error" is thrown. Step S143: Locate the index of "serverMessageId" in _tag_keys using indexOf, and retrieve the value of root_message_id from _tag_vals according to that index. Step S144: Use the retrieved root_message_id as the anchor point for subsequent three-source association queries. Step S145 renders the execution path into a timeline view in ascending order of timestamps, including front-end behavior nodes (page access / click), interface call nodes (SOA / HTTP), data storage access nodes (MySQL / Redis), cache access nodes, and message queue interaction nodes (Kafka / RocketMQ). The technical advantages of this embodiment are: the gateway identifier conversion mechanism allows this method to be compatible with the existing system's gateway tracing system, allowing access to the three-source association system of this invention without modifying existing call chain generation logic; the equal-length verification of the tag array ensures data integrity and prevents incorrect location due to data anomalies; the timeline view arranges the three types of logs in chronological order, allowing operations personnel to intuitively see the complete storyline of "what the user did → what the system called → what the business result was"; the division of multiple node types gives the timeline semantic information, facilitating rapid location of problem areas.

[0044] In a preferred embodiment, step S150, the subscript value query further includes a time window aggregation step. For example, to query "the distribution of successful payment service requests in the past hour by minute", the system buckets the timestamps by toStartOfMinute(timestamp), filters services based on common_vals[indexOf(common_keys,'service_name')] = 'payment-service', filters statuses based on business_vals[indexOf(business_keys,'status')] = 'success', and counts the results by time bucket group using count(). A single query is set to LIMIT 200 and sorted by timestamp DESC to control resource consumption. The columnar storage database ClickHouse uses the arrayElement function or directly through array subscript syntax to retrieve values, where the target key's position in the key set is located using the indexOf function, and the corresponding value is retrieved using the value set[indexOf(key set, target key)]. The technical advantages of this embodiment are as follows: Time window aggregation enables operations and maintenance personnel to quickly answer "the time series distribution of a certain indicator in a certain dimension within a specific time range" without the need for pre-calculation of Cube or materialized view; Setting query upper limits and reverse order effectively controls resource consumption in scenarios with large amounts of interface log data, preventing cluster instability due to excessive query data; Using native array functions of columnar storage database to achieve index positioning fully leverages the advantages of the vectorized execution engine of columnar storage, resulting in query performance superior to traditional JSON parsing or LIKE fuzzy matching methods.

[0045] In a preferred embodiment, step S160, anchor navigation includes steps S161 to S163: An anchor button (e.g., "View Failure Reason") is preset on the interface node of the timeline. When the user clicks this anchor, the system matches the index value in the business log set associated with root_message_id based on preset business field value conditions (e.g., "status=failed") and tag key conditions (e.g., "tag key error_code exists"). If a match is found, the corresponding business log is highlighted. In-page drill-down expands the business log list locally within the current query context using asynchronous loading (Ajax), without redirecting to a separate page.

[0046] In a preferred embodiment, step S160, the linked display of indicators includes steps S164 to S166: when a user selects a "failed to reschedule" business log, the system parses the "status", "channel", "level" and other keys in business_keys as optional analysis dimensions; after the user selects the "channel" dimension, the system queries the number of order records for each payment channel from the business log set based on this dimension and the current time window (e.g., 30 minutes before and after the selected log); the results are rendered as a trend chart (Line / Area, showing the changes of each channel over time) and a distribution chart (Bar / Pie, showing the proportion of each channel), so that the aggregated trend of a single log and its corresponding dimension is presented in the same view. The technical advantages of this embodiment are as follows: Anchor point jump enables precise drill-down from the interface layer to the business layer, allowing users to jump directly from interface timeout exceptions to the corresponding business failure logs without manually writing query statements; In-page drill-down maintains the query context without loss through asynchronous loading, allowing users to seamlessly switch between the timeline view and log details, avoiding the context breakage problem of multi-page jumps in traditional solutions; The linked display of metrics enables an insightful experience of "seeing trends in logs," allowing users to see the distribution of that failure dimension throughout the entire time window on the same screen after selecting a failure log, thus quickly determining whether it is an isolated case or a systemic problem, shortening the root cause location time from "hours" to "minutes."

[0047] Figure 2 This is a schematic diagram of the overall architecture of the business log storage method based on link identifiers that implements the present invention. Figure 3 This is a schematic diagram of the structured storage model of business logs in the business log storage method based on link identifier of the present invention. Figure 4 This is a flowchart of the full-link association query process in the business log storage method based on link identifier of the present invention. Figure 5 This is a flowchart of the index value query and time window aggregation process in the business log storage method based on link identifier of the present invention. Figure 6 This is a flowchart of the data format conversion process in the business log storage method based on link identifier of the present invention. Figure 7 This is a schematic diagram illustrating the anchor point jump and indicator linkage drill-down in the business log storage method based on link identifier of the present invention. The following is in conjunction with... Figures 1 to 7 Taking a single flight ticket rescheduling operation as an example, the most complete and specific implementation scheme of the present invention will be described in detail.

[0048] I. System Overall Architecture and Deployment

[0049] like Figure 2 As shown, the system of the present invention is deployed in a distributed microservice environment, and the overall architecture is divided into an application layer, an association layer, a business structured storage layer, and a query and display layer.

[0050] At the application layer, the front-end behavior tracking module is deployed on the client (App / Web), collecting user behaviors such as page visits, clicking the "Confirm Rescheduling" button, and form input on the rescheduling page through the UBT (User Behavior Tracking) SDK. The system interface collection module is based on the ByteBuddy bytecode enhancement framework. At application startup, it mounts probes via the JVM parameter -javaagent, non-intrusively intercepting the entry and exit points of the SOA / HTTP interfaces between the rescheduling service, ticketing service, and payment service. The business log collection module is actively called in the business code through the LogClient, outputting business semantic logs such as "Seat locking failed, reason = insufficient inventory". All three types of logs carry the global link identifier root_message_id.

[0051] like Figure 8 As shown, the system includes a log collection module, a structured storage module, a new business module, a relational query module, an aggregation statistics module, and a linked display module. The log collection module asynchronously delivers three types of logs to the relational and storage layers through the Kafka message middleware.

[0052] II. Generation and transmission of global link identifiers (corresponding to S110)

[0053] refer to Figure 1 and Figure 2 When a user initiates a rescheduling operation on the App, the gateway layer first generates a globally unique root_message_id for that HTTP request (e.g., "RMI-20260122-A1B2C3D4E5F6"). This identifier is used throughout the entire business process via the following path: According to step S111, the gateway puts the root_message_id into the header (X-Root-Message-Id) of the HTTP request and also into the thread context (ThreadLocal). When the rescheduling service calls the ticketing service via RPC, the root_message_id is passed as an implicit parameter through Dubbo's RpcContext.

[0054] According to step S112, the front-end UBT SDK extracts the root_message_id from the header of the server's HTTP response and includes it in all subsequent front-end behavior logs, including the click event log of the user clicking the "Confirm Rescheduling" button and the page access log of the rescheduling result page.

[0055] According to step S113, when the ByteBuddy probe intercepts the entry point of the ticket change service calling the issueTicket service interface, it extracts the root_message_id from the current thread context and writes it into the tag array _tag_keys (key is "serverMessageId") and _tag_vals (value is "RMI-20260122-A1B2C3D4E5F6") in the interface log.

[0056] According to step S114, when the business application determines that the inventory is insufficient during the rescheduling process, it calls the log client client.log("Seat lock failed, reason = insufficient inventory"). The log client automatically obtains the root_message_id from the thread context and writes it into the fixed-length field root_message_id in the business log.

[0057] Through the above transmission link, all three types of logs ultimately carry the same root_message_id="RMI-20260122-A1B2C3D4E5F6", providing a unified anchor point for subsequent association.

[0058] III. Data Format Conversion and Structured Storage (corresponding to S120)

[0059] like Figure 6 The data format conversion process shown performs the following conversions when business logs are delivered from the business application to the ClickHouse inbound pipeline via Kafka: Step S121: Rename the fields: The original field names in the Kafka message are __message (message content), __level (log level), and @timestamp (timestamp). Rename them to message, level, and timestamp respectively through pipeline configuration to restore their original semantics.

[0060] Step S122 Array Deserialization: In the Kafka message, the common_keys field is a JSON string formatted as "["host","env","service_name"]", common_vals is "["10.0.1.1","prod","payment-service"]", business_keys is "["status","channel"]", and business_vals is "["failed","alipay"]". The pipeline uses ClickHouse's JSONExtract function or custom deserialization logic to convert these strings into an Array(String) type before writing them.

[0061] like Figure 3 As shown in the business log structured storage model, the final record structure written to the ClickHouse business table is as follows: Fixed-length fields: root_message_id = "RMI-20260122-A1B2C3D4E5F6" (String type, used as the primary key index) timestamp = "2026-01-22 14:32:18.123456789" (DateTime64(9) type, nanosecond precision) order_number = "ORD-2026-0122-00342" (String type) uid = "user_zhangsan" (String type) cid = "device_iphone_001" (String type) title = "Rebooking Process - Seat Lock" (String type) level = "ERROR" (String type) Variable-length arrays: common_keys = ["host","env","service_name"] common_vals = ["10.0.1.1","prod","payment-service"] business_keys = ["status","channel","error_code"] business_vals = ["failed","alipay","STOCK_001"] IV. No DDL field extension (corresponding to S130) Suppose that one week after the rescheduling process went live, the business team wants to add a "Membership Level" dimension to analyze the rescheduling failure rate for different membership levels. According to step S130, the business team doesn't need to contact the DBA to perform an ALTER TABLE operation; they only need to add the field mapping "level=$.user.level" to the log client configuration and append key-value pairs in the business code via the log client. When writing new logs, append "level" to business_keys and append "gold" to business_vals at the same index. The new business log record will look like this: business_keys = ["status","channel","error_code","level"] business_vals = ["failed","alipay","STOCK_001","gold"] Once the write operation is complete, the query side can immediately filter and aggregate using the "level" field by index value, without any additional configuration or waiting. This expansion process has zero impact on the running system, and the expansion cycle is shortened from days to minutes.

[0062] V. Full-link correlation query and timeline rendering (corresponding to S140)

[0063] refer to Figure 4 The full-link relational query flowchart shows that when operations and maintenance personnel receive the alarm "Order ORD-2026-0122-00342 Rescheduling Failed", they execute the following query process: Step S140 uses root_message_id="RMI-20260122-A1B2C3D4E5F6" as the anchor point to query three types of data sources respectively: Front-end behavior log (UBT table): SELECT FROM ubt_log WHERE root_message_id='RMI-20260122-A1B2C3D4E5F6' System Interface Log (SOA Table): SELECT FROM soa_log WHERE root_message_id='RMI-20260122-A1B2C3D4E5F6' Business Log (CK Business Table): SELECT FROM business_ck_table WHERE root_message_id='RMI-20260122-A1B2C3D4E5F6' AND timestamp >= toDateTime('2026-01-22 14:30:00') AND timestamp <= toDateTime('2026-01-22 14:35:00') ORDER BYtimestamp DESC LIMIT 200 If the user provides only the gateway tracing identifier gateway_trace_id="GT-20260122-001" instead of the root_message_id, then the gateway identifier conversion step will be performed. Step S141: Query the record with gateway_trace_id='GT-20260122-001' from the SOA table. Step S142: Verify that _tag_keys=["traceId","serverMessageId","appId"] and _tag_vals=["GT-20260122-001","RMI-20260122-A1B2C3D4E5F6","payment-service"] are of equal length. Step S143: Locate "serverMessageId" at index 2 (counting from 1) using indexOf, and retrieve root_message_id="RMI-20260122-A1B2C3D4E5F6" from _tag_vals according to that index.

[0064] After merging the three types of logs in ascending order of timestamp, the timeline view is rendered according to step S145, containing the following nodes: 14:32:17.001 Front-end behavior node: User clicks the "Confirm Rescheduling" button 14:32:17.235 Interface call node: Ticket change service → Ticket issuance service (time taken 235ms) 14:32:17.512 Data storage access node: Query inventory table (time taken 12ms) 14:32:17.523 Business Log Node: ERROR "Seat locking failed, reason = insufficient inventory" 14:32:17.789 Interface call node: Rescheduling service → Payment service refund (rollback payment, time taken 266ms) 14:32:18.123 Business Log Node: INFO "Rescheduling Failed, Process Completed" VI. Subscript value lookup and time window aggregation (corresponding to S150) refer to Figure 5 The flowchart illustrates the subscript value query and time window aggregation process. After selecting the rescheduling failure node in the timeline, the operations and maintenance personnel want to further analyze the distribution trend of "insufficient inventory" errors within the same time window. The system executes the following query: Step S150 uses index-based positioning: Locate the index of the target key "error_code" within `business_keys`. For example, if a business log entry has `business_keys=["status","channel","error_code"]`, `indexOf(business_keys,'error_code')` returns index 3. Then, retrieve the value from `business_vals` using that index. business_vals[indexOf(business_keys,'error_code')] takes out "STOCK_001".

[0065] Example of time window aggregation: Query "Distribution of out-of-stock errors in the rescheduling service within the last 30 minutes": SELECT toStartOfMinute(timestamp) AS time_bucket, count() AS error_count FROM business_ck_table WHERE timestamp >= now() - INTERVAL 30 MINUTE AND common_vals[indexOf(common_keys,'service_name')] = 'change-service' AND business_vals[indexOf(business_keys,'error_code')] = 'STOCK_001' GROUP BY time_bucket ORDER BY time_bucket This query uses ClickHouse's arrayElement function to retrieve the index value, returns the number of out-of-stock errors per minute over the past 30 minutes in milliseconds, and renders it as a trend chart displayed in the side panel.

[0066] Setting LIMIT 200 for a single query and sorting by timestamp DESC ensures that even when the business table contains billions of records, the resource consumption of a single query is kept within a reasonable range, avoiding excessive cluster load due to scanning large amounts of data.

[0067] VII. Anchor point navigation and drill-down within the page (corresponding to S161 to S163 of S160)

[0068] refer to Figure 7 In the timeline view, the API call node "Rescheduling Service → Ticketing Service (issueTicket)" has a pre-defined anchor button "View Business Details". When operations personnel click this anchor button, the system performs the following operations: According to steps S161 to S163, the system reads the preset matching conditions of the anchor point: the business field value conditions are "business type = rescheduling" and "status = failed", and the tag key condition is "error_code exists". In the business log set obtained by associating with root_message_id, the system matches these conditions by the index value. After matching the business log "seat locking failed, reason = insufficient inventory", it automatically locates and highlights the entry.

[0069] Based on the page drill-down mechanism, after the anchor point is triggered, the business log list panel is expanded on the current page via an asynchronous Ajax request (e.g., ...). Figure 7 Instead of redirecting to a separate log query page, operations and maintenance personnel can seamlessly switch between the timeline view and business log details, maintaining the continuity of the query context, by viewing the upper half of the log (as shown).

[0070] 8. Indicator Linkage Display (corresponding to S164 to S166 of S160)

[0071] When maintenance personnel select the log entry "Seat lock failed, reason = insufficient inventory" in the expanded business log list, the system execution metrics will be displayed in conjunction: According to step S164, the system parses the log's business_keys = ["status","channel","error_code","level"], and uses "status", "channel", "error_code", and "level" as optional analysis dimensions.

[0072] According to step S165, after the user selects the "error_code" dimension, the system constructs an aggregate query of the index value based on this dimension and the current time window (30 minutes before and after the selected log): SELECT business_vals[indexOf(business_keys,'error_code')] AS error_code, count() AS count FROM business_ck_table WHERE timestamp >= '2026-01-22 14:02:18' AND timestamp <= '2026-01-2215:02:18' AND common_vals[indexOf(common_keys,'service_name')] = 'change-service' GROUP BY error_code ORDER BY count DESC According to step S166, the query results are rendered into a trend chart (showing the changing trends of various error codes such as STOCK_001 and TIMEOUT_002 over a 30-minute time window) and a distribution chart (showing the proportion of each type of error code), displayed in the chart management panel. This allows a single "Insufficient Inventory" log entry and the overall trend of the "STOCK_001" error code to be presented in the same view, enabling operations personnel to quickly determine whether the error is an isolated case at a specific time point or a continuously escalating systemic problem, achieving a "see the trend in the log" insightful experience.

[0073] 9. Chart configuration and business logic binding are independent.

[0074] like Figure 7 As shown, the chart management module of the present invention supports the separation of chart configuration and business binding.

[0075] In a complete implementation plan, operations and maintenance personnel pre-configure a chart called "Rescheduling Failure Error Code Distribution," which includes the following: Chart ID: CHART_ERR_001 Chart type: Bar (column chart) Query statement: SELECT business_vals[indexOf(business_keys,'error_code')] AS error_code, count() AS count FROM business_ck_table WHERE timestamp >= now() -INTERVAL 1 HOUR AND business_vals[indexOf(business_keys,'status')] = 'failed' GROUP BY error_code ORDER BY count DESC Purpose Description: Displays the distribution of various error codes for failed rescheduling within the past hour. The chart configuration is stored in a separate chart_config table.

[0076] Then, the operations and maintenance personnel bound the chart CHART_ERR_001 to "Change Service - Execute Change Interface" (appId='change-service', serviceKey='change-interface', interfaceName='executeChange'), and the binding rule also specified the optional condition "Business Product Line = Domestic Air Tickets". The binding relationship is stored in a separate chart_binding table.

[0077] The same chart, CHART_ERR_001, is also bound to the "International Flights" business line (with the specified condition "business line = international flights"). When the operations and maintenance personnel of the domestic flight business line view the rescheduling service panel, the system finds the binding relationship in chart_binding, retrieves the chart configuration CHART_ERR_001, and automatically appends the condition "AND common_vals[indexOf(common_keys,'biz_line')]='domestic flights'" to the query statement. After executing the query, it displays the distribution of rescheduling failure error codes for the domestic flight business line. When the operations and maintenance personnel of the international flight business line view the same chart, they see the data from the international flight business line.

[0078] The technical advantages of this solution are as follows: charts, as reusable analytical assets, can be configured once and used for multiple business lines, avoiding repetitive configuration work; the introduction of business binding conditions enables the same chart to automatically adapt to different data ranges in different business contexts, realizing intelligent analysis capabilities of "configure once, use everywhere, and filter on demand"; the decoupling of chart configuration and binding relationships enables chart upgrades (such as adjusting time granularity or adding analytical dimensions) to take effect automatically on all bound business lines, significantly reducing operation and maintenance costs.

[0079] 10. Complete Business Scenario Replay

[0080] The above steps are now integrated into a complete business scenario: At 14:32:17 on January 22, 2026, user Zhang San (Member Level: Gold) initiated a flight rescheduling operation on the App, from Beijing to Shanghai, flight number CA1234. The system generated root_message_id="RMI-20260122-A1B2C3D4E5F6" which is used throughout the entire process.

[0081] The front-end UBT collects the action log of "clicking the confirm rescheduling button", carrying the root_message_id. After receiving the request, the rescheduling service calls the ticketing service's issueTicket interface. ByteBuddy probes collect interface logs, carrying the root_message_id. When the ticketing service finds insufficient stock while locking seats, the business application outputs the business log "Seat locking failed, reason = insufficient stock" through the log client, carrying the root_message_id, and records status="failed", error_code="STOCK_001", and level="gold" in business_keys.

[0082] After receiving the rescheduling failure alert, the operations and maintenance personnel entered the order number ORD-2026-0122-00342 into the query platform. The system automatically associated it with the root_message_id. A single query returned a complete timeline view (e.g., Figure 4 As shown in the image, the entire process from user click to API call to business failure is displayed. The operations and maintenance personnel click the anchor button on the "Rebooking Service → Ticketing Service" API node on the timeline. Drilling down the page expands the business log list, automatically highlighting "Seat locking failed, reason = insufficient inventory." After selecting this log, the right panel displays a trend chart of STOCK_001 error codes over the past 30 minutes. A sharp increase in this error code was observed in the last 5 minutes, indicating a global inventory system anomaly rather than a single order issue. The inventory team was immediately notified for handling.

[0083] The entire location process took less than 3 minutes, while the traditional approach requires querying the front-end log system, interface tracing system, and business log system separately, which takes at least 30 minutes.

[0084] Through the above complete implementation scheme, the present invention fully realizes the technical effects described in the invention's purpose: restoring the complete context through three-source one-time association, flexibly expanding business indicators without DDL, and displaying logs and indicators in linkage, improving the efficiency of problem location from "hourly system-by-system investigation" to "minute-level one-screen location".

[0085] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

[0086] Figure 8 This is a system architecture diagram of the business log storage system based on link identification according to the present invention. Figure 8As shown, the service log storage system 5 based on link identifier of the present invention includes: The log collection module 51 is used to determine a global link identifier for a business operation. The global link identifier is consistent across the front-end behavior log, system interface log, and business processing log of the business operation, and is written to the columnar storage database along with the business log as a unique anchor point for cross-three-source association. The structured storage module 52 is used to write business logs into the columnar storage database in a mixed mode of fixed-length fields and variable-length arrays. The fixed-length fields include at least a global link identifier and a timestamp. The variable-length array includes at least a first key set and a first value set, a second key set and a second value set. The key set and value set in the same group are of equal length and correspond one-to-one with the index. A new business module 53 has been added. When a new business indicator field needs to be added, no table structure change operation is performed. Instead, when writing to the business log, the key name is appended to the second key set and the corresponding value is appended to the second value set at the same index position. The new field can then be used for filtering, grouping, aggregation, and statistics during the query. The associated query module 54 is used to retrieve records carrying the global link identifier from the front-end behavior log data source, system interface log data source, and business processing log data source respectively, and sort and merge the three types of logs by timestamp to restore the complete execution path of the business operation. The aggregation statistics module 55 is used to perform key-value filtering or group aggregation statistics on business logs that have been retrieved by the global link identifier in the related query module. First, it locates the index position of the target key in the corresponding key set, and then performs a value query from the corresponding value set according to the index to obtain the value result. Based on the obtained value, it performs filtering or group aggregation statistics. The linked display module 56 is used to provide anchor jumps, drill-down within the page, and linked display of indicators based on the associated query results.

[0087] In summary, the business log storage system based on link identification of the present invention can restore the complete context of a business operation by associating the front-end behavior, interface call and business processing log with a unified anchor point; business indicator fields can be flexibly expanded without modifying the table structure (DDL); a single log and the indicator trend of its dimension can be presented in the same view; thereby improving the efficiency of problem localization from "hourly system-by-system investigation" to "minute-level one-screen localization".

[0088] This invention also provides a link-identifier-based service log storage device, including a processor and a memory storing executable instructions for the processor. The processor is configured to execute steps of a link-identifier-based service log storage method by executing the executable instructions.

[0089] As shown above, the business log storage device based on link identifier of this invention can restore the complete context of a business operation by associating the front-end behavior, interface call and business processing log with a unified anchor point; business indicator fields can be flexibly expanded without modifying the table structure (DDL); a single log and the indicator trend of its dimension can be presented in the same view; thereby improving the efficiency of problem location from "hourly system-by-system investigation" to "minute-level one-screen location".

[0090] Those skilled in the art will understand that various aspects of the present invention can be implemented as systems, methods, or program products. Therefore, various aspects of the present invention can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "platform."

[0091] Figure 9 This is a schematic diagram of the service log storage device based on link identifier according to the present invention. See below for reference. Figure 9 To describe an electronic device 600 according to this embodiment of the present invention. Figure 9 The electronic device 600 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.

[0092] like Figure 9 As shown, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different platform components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0093] The storage unit stores program code, which can be executed by the processing unit 610 to perform the steps described in the method section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 610 can perform actions such as... Figure 1 The steps are shown in the figure.

[0094] Storage unit 620 may include readable media in the form of volatile storage units, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include read-only memory (ROM) 6203.

[0095] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0096] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the multiple bus structures.

[0097] Electronic device 600 can also communicate with one or more external devices 700 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage platforms.

[0098] This invention also provides a computer-readable storage medium for storing a program, which, when executed, implements the steps of a link-identifier-based service log storage method. In some possible implementations, various aspects of this invention can also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the above-described method section of this specification according to various exemplary embodiments of the invention.

[0099] As shown above, the business log storage system based on link identifier of this invention can restore the complete context of a business operation by associating the front-end behavior, interface call and business processing log with a unified anchor point; business indicator fields can be flexibly expanded without modifying the table structure (DDL); a single log and the indicator trend of its dimension can be presented in the same view; thereby improving the efficiency of problem location from "hourly system-by-system investigation" to "minute-level one-screen location".

[0100] Figure 10 This is a schematic diagram of the structure of the computer-readable storage medium of the present invention. (Reference) Figure 10 As shown, a program product 800 for implementing the above-described method according to an embodiment of the present invention is described. It may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0101] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0102] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0103] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0104] In summary, the purpose of this invention is to provide a business log storage method, system, device, and storage medium based on trace identifiers, which has the following beneficial effects: By sinking global trace identifiers to business logs and front-end logs, three types of data sources are associated in a single query with a unified anchor point, overcoming the shortcomings of existing traceIds that only cover the interface layer and the fragmentation of the three sources, making unified querying impossible. This achieves a single association of the three sources and restores the complete context. Through a hybrid storage model of "fixed-length fields + variable-length arrays," adding new business fields only requires appending key values ​​to the array, without DDL, overcoming the high cost of expanding fixed column structures and shortening the indicator expansion cycle from "day-level coordination" to "instant effect." Utilizing the array functions of columnar storage databases, values ​​are retrieved by index during queries. Combined with time-based bucketing aggregation, the "time-series distribution and trend of a certain indicator in a certain dimension" can be flexibly answered without pre-calculation. Asynchronous batch writing of business logs ensures that log collection has zero impact on the time consumption of business requests. By using anchor jumps, drill-down within pages, and linked display of metrics, the ability to directly transform structured storage and index value retrieval into user-facing visual insights. This overcomes the shortcomings of the separation between logs and metrics, upgrading problem localization from "manual association through multiple system jumps" to "one-screen linkage and minute-level localization".

[0105] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A method for storing business logs based on link identifiers, characterized in that, Includes the following steps: S110. Determine a global link identifier for a business operation. The global link identifier is consistent across the front-end behavior log, system interface log, and business processing log of the business operation, and is written to the columnar storage database along with the business log as a unique anchor point for cross-three-source association. S120. Write the business logs into the columnar storage database in a mixed mode of fixed-length fields and variable-length arrays. The fixed-length fields include at least a global link identifier and a timestamp. The variable-length arrays include at least a first key set and a first value set, a second key set and a second value set. The key set and value set in the same group are of equal length and correspond one-to-one with the index. S130. When it is necessary to add a new business indicator field, the table structure change operation is not performed. Instead, when writing to the business log, the key name is appended to the second key set and the corresponding value is appended to the second value set at the same index position. When querying, the new field can be used for filtering, grouping, aggregation and statistics. S140. When querying, use the global link identifier as the anchor point to retrieve records carrying the identifier from the front-end behavior log data source, system interface log data source, and business processing log data source respectively. Sort and merge the three types of logs by timestamp to restore the complete execution path of the business operation. S150. When performing key-value filtering or group aggregation statistics on the business logs obtained by global link identifier retrieval in step S140, first locate the index position of the target key in the corresponding key set, then perform value query from the corresponding value set according to the index to obtain the value result, and perform filtering or group aggregation statistics based on the obtained value. S160. Based on the related query results, provide anchor jump, drill-down within the page and linked display of indicators.

2. The service log storage method based on link identifier as described in claim 1, characterized in that, Step S110 includes: S111. After the global link identifier is generated at the interface layer, it is transmitted to the downstream of the business processing link through the thread context or request context to ensure that all processing links of the same business operation obtain the same identifier value. S112. Front-end behavior logs are collected through a front-end event tracking system. The front-end event tracking system obtains the global link identifier from the server-side interface response and carries it in the front-end behavior logs. S113. System interface logs are collected non-intrusively using a bytecode enhancement probe. When the probe intercepts the system interface entry and exit, it extracts the global link identifier in the current thread context and writes it into the interface log. S114. The business processing log is output by the business application actively calling the log client. The log client obtains the global link identifier from the current thread context and writes it into the business log.

3. The service log storage method based on link identifier as described in claim 1, characterized in that, In step S120: the fixed-length field further includes at least one of order number, user identifier, and device identifier, as a business association auxiliary field; the first key set carries the key name of the common dimension, and the first value set carries the common dimension value that is the same length as the first key set and corresponds one-to-one with the index; the second key set carries the key name of the business indicator, and the second value set carries the business indicator value that is the same length as the second key set and corresponds one-to-one with the index; the fixed-length field is determined when the table is created and serves as the direct index field during querying, and the variable-length array is stored using the native array type of the columnar storage database; A data format conversion step is included before step S120: S121. Rename the fields with naming prefixes passed by the upstream message middleware to restore their original field names; S122. The four array fields, namely the first key set, the first value set, the second key set, and the second value set, are deserialized from the string form during the transmission stage into array type and then stored. The business logs are written to the columnar storage database in an asynchronous batch writing mode, and the main business thread is not blocked or waits for the writing to be completed.

4. The service log storage method based on link identifier as described in claim 1, characterized in that, In step S140, when the query entry only provides a gateway tracing identifier instead of a global link identifier, a gateway identifier conversion step is also included: S141. Query the record corresponding to the gateway tracking identifier from the system interface log. If the corresponding record is found, obtain the tag key array and tag value array of the record. If it is not found, prompt that the gateway tracking identifier is invalid. S142. Verify that the tag key array and the tag value array are of equal length; S143. Locate the target key in the tag key array using the index positioning method, and retrieve the value of the global link identifier from the tag value array by the index; S144. Use the extracted global link identifier as the anchor point for subsequent three-source association queries; S145. Render the execution path of the business operation into a timeline view in ascending order of timestamps. The timeline includes the following node types: front-end behavior nodes, interface call nodes, data storage access nodes, cache access nodes, and message queue interaction nodes.

5. The service log storage method based on link identifier as described in claim 1, characterized in that, In step S150: the subscript value query further includes a time window aggregation step: the timestamps of the business logs are divided into buckets according to a preset time granularity, and the results of the subscript values ​​of the target key in the first key set or the second key set are filtered and statistically analyzed by time bucket. Set a query limit for each query and sort query results in descending order of timestamp to control resource consumption; The columnar storage database uses array index positioning functions to implement key-value queries. The position of the target key in the key set is located by the indexOf function, and the corresponding value is retrieved by the value set [indexOf(key set, target key)].

6. The service log storage method based on link identifier as described in claim 1, characterized in that, The anchor point jump in step S160 includes: S161. Preset anchor points on the interface nodes or business log nodes of the timeline; S162. When a user triggers an anchor point, a match is made in the set of business logs associated with the global link identifier based on the business field value conditions or tag key conditions specified by the user. S163. Upon a hit, the system automatically locates the corresponding business log and highlights it. The tag key condition includes two matching modes: the specified tag key exists and the specified tag key equals a specified value. The drill-down within the page includes: after triggering the anchor point, the system expands the list of business logs associated with the current node in the current query context in an asynchronous manner, rather than jumping to an independent page, in order to maintain the continuity of the query context.

7. The service log storage method based on link identifier as described in claim 1, characterized in that, The linked display of indicators in step S160 includes: S164. When a user selects a business log, the system parses the keys carried in the variable-length array of that business log as the analysis dimension. S165. Based on the analysis dimension and the current time window, query records of the same dimension from the business log set; S166. Render the query results as a trend chart changing over time and a distribution chart by dimension, so that the aggregate trend and distribution of a single log and its corresponding dimension are presented in the same view.

8. A service log storage system based on link identifier, used to implement the method of any one of claims 1 to 7, characterized in that, include: The log collection module is used to determine a global link identifier for a business operation. The global link identifier is consistent across the front-end behavior log, system interface log, and business processing log of the business operation, and is written to the columnar storage database along with the business log as a unique anchor point for cross-three-source association. The structured storage module is used to write business logs into a columnar storage database in a mixed mode of fixed-length fields and variable-length arrays. The fixed-length fields include at least a global link identifier and a timestamp. The variable-length array includes at least a first key set and a first value set, a second key set and a second value set. The key set and value set in the same group are of equal length and correspond one-to-one with the index. The new business module is used to add a new business indicator field without performing a table structure change operation. Instead, it adds the key name to the second key set and the corresponding value to the second value set at the same index position when writing to the business log. The new field can then be used for filtering, grouping, aggregation, and statistics during the query. The related query module is used to retrieve records carrying the global link identifier from the front-end behavior log data source, system interface log data source, and business processing log data source respectively when querying. The three types of logs are sorted by timestamp and merged to restore the complete execution path of the business operation. The aggregation statistics module is used to perform key-value filtering or group aggregation statistics on business logs retrieved by the global link identifier in the related query module. First, it locates the index position of the target key in the corresponding key set, and then performs a value query from the corresponding value set according to the index to obtain the value result. Based on the obtained value, it performs filtering or group aggregation statistics. The linked display module is used to provide anchor jumps, drill-down within the page, and linked display of indicators based on related query results.

9. A service log storage device based on link identifier, characterized in that, include: processor; A memory in which executable instructions of the processor are stored; The processor is configured to perform the steps of the service log storage method based on link identifier according to any one of claims 1 to 7 by executing the executable instructions.

10. A computer-readable storage medium for storing a program, characterized in that, When the program is executed by the processor, it implements the steps of the service log storage method based on link identifier as described in any one of claims 1 to 7.

Images