A trace back method and system based on cooperative reuse of conversational state node sources and persistent node sources

Abstract

The application provides a Trace backtracking method and system based on cooperative multiplexing of conversational state node sources and persistent node sources, which comprises the following steps: S1, conversational state node source reading; S2, real-time cache node source reading; S3, persistent node source backtracking; S4, persistent key conversion; S5, unified node mapping; S6, result distribution; and S7, backtracking source identification. The application reduces the repeated access times of databases and caches, reduces the overhead of deserialization operations, shortens the response time with the upward movement of the hit level, adopts the same set of key mapping rules for historical playback and real-time playback, and uniformly processes the data without distinguishing the data sources on the front-end page. Only the data that passes all the checks can enter the display process, so that the dirty data can be effectively intercepted. Once an exception occurs, the complete path of the data can be directly backtracked to quickly locate the problem link. The application provides a clear basis for investigating performance problems and data missing problems, and improves the problem locating efficiency.

Description

Technical Field

[0001] This invention relates to the field of software, and specifically to a trace back method based on the collaborative reuse of session-state node sources and persistent node sources. Background Technology

[0002] When viewing trace graphs and node details in online monitoring, users are more concerned with low-latency playback. However, single-node sources are prone to issues such as missed nodes or incomplete nodes. If the trace graph page and node details page each query the trace node again, it will incur duplicate I / O and duplicate parsing overhead. Runtime nodes are usually organized using traceNodeId, while persistent nodes usually use composite primary keys. Without a unified key model, real-time data and persistent data are difficult to reuse.

[0003] These issues further lead to: a lack of a unified backtracking order among sessions, real-time caching, and persistent node sources; the graph and details not sharing the same node mapping, resulting in high costs for repeated construction; and a lack of unified rules for runtime key to persistent key conversion, causing fragmented replay chains. Summary of the Invention

[0004] To address the aforementioned issues, this invention provides a Trace backtracking method based on the collaborative reuse of session-state node sources and persistent node sources.

[0005] The specific plan is as follows: A trace backtracking method based on the collaborative reuse of session-state node sources and persistent node sources includes the following steps: S1. Session-state node source reading: Receive Trace backtracking request, the request including at least traceId and replay scene identifier; S2. Real-time cache node source reading: Construct a session key sessionKey = model- + traceId based on traceId, and query the set of trace nodes in the current session; if the query is successful and the node set passes the integrity check, then the node set is used as a candidate node source; S3. Persistent Node Source Backtracking: If the session-state node source is not found or fails the integrity check, then construct the real-time cache key trace:nodes:{traceId} based on traceId and query the real-time node cache; if the query is found and passes the integrity check, then the set of real-time cache nodes is used as the candidate node source. S4. Persistent Key Conversion: If both the session-state node source and the real-time cache node source are unavailable, or if the replay scenario requires historical tracing, then query the persistent node records in the form of traceId_traceNodeId and restore the persistent records to a set of TraceNode nodes; S5. Unified Node Mapping: Perform unified key processing on the candidate node set, writing each node into a Map using the traceNodeId as the runtime key.<traceNodeId, TraceNode> For persistent node records, the traceNodeId is first split or restored from the traceId_traceNodeId primary key. S6. Result Distribution: Distribute the Map...<traceNodeId, TraceNode> Write to the request context or replay context, and simultaneously provide it to the graph construction module, node details module, and snapshot viewing module for reuse; S7. Backtracking Source Identifier: Output backtracking results, which include at least nodeMap, sourceType, nodeCount, and fallbackReason.

[0006] Further, in step S1, the set of trace nodes in the current session is queried based on sessionKey = "model-" + traceId. If a match is found and passes the integrity check, it is used as a candidate node source. The advantage of this is that when the current user has just finished building the graph or when the current request context still retains nodes, memory data can be directly reused, reducing caching or database access.

[0007] Furthermore, in step S2, when the session-state node source is not found or the verification fails, this component queries the real-time node cache based on cacheKey = "trace:nodes:" + traceId; if it is found and passes the integrity verification, it is used as a candidate node source. The advantage of doing this is that when the session expires but the trace node is still in the cache, there is no need to access persistent storage, reducing historical replay latency.

[0008] Furthermore, in step S3, when both the session state and the real-time cache are unavailable, or when replay scenarios require historical tracing, persistent node records are queried in the form of traceId_traceNodeId and restored as a set of TraceNode nodes. This ensures that historical traces can still be replayed and provides a unified access interface for both real-time and historical data.

[0009] Furthermore, in step S4, the composite primary key in the persistent record is converted into a runtime traceNodeId. The advantage of this is that the same traceNodeId can be used for graph node clicks, node detail queries, and snapshot viewing, avoiding the need for the front-end to separately adapt persistent primary keys and runtime keys.

[0010] Further, in step S5, the set of nodes from any source is converted into: Map<traceNodeId,TraceNode> If duplicate traceNodeIds are found, select records to retain based on source priority or update time, and record the reason for the conflict.

[0011] Furthermore, in step S6, the unified nodeMap is written into the request context or replay context and simultaneously provided to the graph construction module, node details module, and snapshot viewing module.

[0012] Furthermore, in step S7, sourceType, fallbackReason, and nodeCount are output to indicate the path hit in this backtracking.

[0013] A trace back system based on the collaborative reuse of session-state node sources and persistent node sources includes: Session-state node source reading module: used to receive trace back requests, the requests including at least traceId and replay scene identifier; Real-time cache node source reading module: used to construct session key sessionKey = model- + traceId based on traceId, and query the set of trace nodes in the current session; if the query is successful and the node set passes the integrity check, then the node set is used as a candidate node source; Persistent Node Source Backtracking Module: If the session-state node source is not found or fails the integrity check, it constructs a real-time cache key trace:nodes:{traceId} based on traceId and queries the real-time node cache; if the query finds a match and passes the integrity check, the set of real-time cache nodes is used as a candidate node source. Persistent key conversion module: If both the session node source and the real-time cache node source are unavailable, or if the playback scenario requires historical tracing, then the persistent node record is queried in the form of traceId_traceNodeId, and the persistent record is restored to a set of TraceNode nodes; Unified Node Mapping Module: Used to perform unified key processing on the candidate node set, writing each node into a Map using traceNodeId as the runtime key.<traceNodeId, TraceNode> For persistent node records, the traceNodeId is first split or restored from the traceId_traceNodeId primary key. Result Distribution Module: Used to distribute Map results<traceNodeId, TraceNode> Write to the request context or replay context, and simultaneously provide it to the graph construction module, node details module, and snapshot viewing module for reuse; Backtracking source identifier module: used to output backtracking results, which include at least nodeMap, sourceType, nodeCount and fallbackReason.

[0014] The beneficial effects of this invention are as follows: 1. The graph page, details page, and snapshot viewing page share the same nodeMap instance, eliminating the need for each page to independently query trace data repeatedly. This reduces the number of repeated accesses to the database and cache, while also lowering the overhead of deserialization operations.

[0015] 2. Data retrieval follows a three-tiered strategy: it prioritizes directly using data already existing in the current session, avoiding access to the cache and database; if data is missing in the session, it queries the cache; only when the cache is also missing does it fall back to persistent storage for a fallback read. This results in response time decreasing progressively as the hit level increases.

[0016] 3. A composite primary key (traceId_traceNodeId) is used in persistent storage, and after data recovery, it is uniformly converted to traceNodeId as the key identifier. Both historical playback and real-time playback use the same set of key mapping rules, so the front-end page does not need to distinguish the data source and can process them uniformly.

[0017] 4. After obtaining a node, an integrity check is performed first, including: node not empty check, traceId consistency check, and root node existence check. Only data that passes all checks can enter the display process, ensuring that dirty data is effectively intercepted.

[0018] 5. Each data backtracking process records the sourceType (data source type) and fallbackReason (fallback reason). In case of an anomaly, the complete path traversed by the data can be directly traced back to quickly locate the problematic link.

[0019] 6. By recording the sourceType and fallbackReason, the data backtracking path can be fully reconstructed. This provides clear evidence for troubleshooting performance issues and data loss problems, significantly improving the efficiency of problem localization. Attached Figure Description

[0020] Figure 1 This is a flowchart of the method of the present invention.

[0021] Figure 2This is a diagram illustrating the key structure and rules of the present invention.

[0022] Figure 3 This is a preview image of the present invention.

[0023] Figure 4 This is a diagram of the unified nodeMap framework of the present invention.

[0024] Figure 5 This is a rendering of the intended effect. Detailed Implementation

[0025] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. It should be understood that the following specific embodiments are for illustrative purposes only and are not intended to limit the scope of the invention.

[0026] The variables and fields in this invention are described below: Trace: This refers to a tracing or chain of events, used to describe the call path of a single request within the system.

[0027] traceId: Represents the Trace identifier, used to identify a complete link.

[0028] traceNodeId: Represents the identifier of a single node within the trace, which can correspond to spanId or node number, i.e., application method, remote call, database access, cache access, etc.

[0029] sessionKey: Represents the source key of the session node, preferably a concatenation of model- and traceId.

[0030] Session-state node source: Represents a collection of temporary nodes saved in the current user session or the current request context.

[0031] cacheKey: Represents the real-time cache key, preferably a concatenation of trace:nodes: and traceId.

[0032] Real-time cache node source: This refers to the recently reported node cache that is aggregated and saved by traceId.

[0033] persistentKey: Represents the persistent primary key, preferably traceId + "_" + traceNodeId.

[0034] Persistent node source: Represents historical trace node records that are stored in a database or search engine for a long time.

[0035] TraceNode: Represents a Trace node object, which includes at least traceId, traceNodeId, parentTraceNodeId, nodeType, startTime, duration, errorFlag, and attributes.

[0036] nodeMap: Represents a runtime unified node mapping, in the form of a Map.<traceNodeId, TraceNode> .

[0037] sourceType: Indicates the source type of the node that was hit this time, including SESSION, REALTIME_CACHE, and PERSISTENCE.

[0038] fallbackReason: Indicates the reason for falling back to the next node source, such as SESSION_MISS, SESSION_INVALID, CACHE_MISS, CACHE_INVALID.

[0039] nodeCount: Represents the number of nodes obtained through backtracking.

[0040] like Figure 1-3 As shown, this invention provides a trace back method based on the collaborative reuse of session-state node sources and persistent node sources, including the following steps: S1. Session-state node source reading: Receive Trace backtracking request, the request including at least traceId and replay scene identifier; S2. Real-time cache node source reading: Construct a session key sessionKey = model- + traceId based on traceId, and query the set of trace nodes in the current session; if the query is successful and the node set passes the integrity check, then the node set is used as a candidate node source; S3. Persistent Node Source Backtracking: If the session-state node source is not found or fails the integrity check, then construct the real-time cache key trace:nodes:{traceId} based on traceId and query the real-time node cache; if the query is found and passes the integrity check, then the set of real-time cache nodes is used as the candidate node source. S4. Persistent Key Conversion: If both the session-state node source and the real-time cache node source are unavailable, or if the replay scenario requires historical tracing, then query the persistent node records in the form of traceId_traceNodeId and restore the persistent records to a set of TraceNode nodes; S5. Unified Node Mapping: Perform unified key processing on the candidate node set, writing each node into a Map using the traceNodeId as the runtime key.<traceNodeId, TraceNode> For persistent node records, the traceNodeId is first split or restored from the traceId_traceNodeId primary key. S6. Result Distribution: Distribute the Map...<traceNodeId, TraceNode> Write to the request context or replay context, and simultaneously provide it to the graph construction module, node details module, and snapshot viewing module for reuse; S7. Backtracking Source Identifier: Output backtracking results, which include at least nodeMap, sourceType, nodeCount, and fallbackReason.

[0041] In step S1, the set of trace nodes in the current session is queried based on sessionKey = "model-" + traceId. If a match is found and passes the integrity check, it is used as a candidate node source. The advantage of this approach is that when the current user has just finished building the graph or when the current request context still retains nodes, in-memory data can be directly reused, reducing caching or database access.

[0042] In step S2, when the session-state node source is not found or the verification fails, this component queries the real-time node cache based on cacheKey = "trace:nodes:" + traceId; if it is found and passes the integrity verification, it is used as a candidate node source. The advantage of this is that when the session expires but the trace node is still in the cache, there is no need to access persistent storage, reducing historical replay latency.

[0043] In step S3, when both the session state and the real-time cache are unavailable, or when replay scenarios require historical tracing, persistent node records are queried in the form of traceId_traceNodeId and restored as a set of TraceNode nodes. This ensures that historical traces can still be replayed and provides a unified access interface for both real-time and historical data.

[0044] In step S4, the composite primary key in the persistent record is converted into a runtime traceNodeId.

[0045] For example: persistentKey = T20260325_009_1.remote traceId = T20260325_009 traceNodeId = 1.remote nodeMap["1.remote"] = TraceNode The advantage of doing this is that the same traceNodeId can be used for graph node clicks, node detail queries, and snapshot viewing, avoiding the need for the front end to adapt persistent primary keys and runtime keys separately.

[0046] In step S5, the set of nodes from any source is converted into a Map.<traceNodeId, TraceNode> If duplicate traceNodeIds are found, select records to retain based on source priority or update time, and record the reason for the conflict.

[0047] In step S6, the unified nodeMap is written into the request context or replay context, and simultaneously provided to the graph construction module, node details module, and snapshot viewing module (e.g., Figure 4 (As shown).

[0048] In step S7, the output sourceType, fallbackReason, and nodeCount are used to describe the path hit in this backtracking.

[0049] Example output: { "traceId": "T20260325_001", "sourceType": "REALTIME_CACHE", "fallbackReason": "SESSION_MISS", "nodeCount": 47 }

[0050]

[0051] Processing procedure: 1. The system constructs sessionKey=model-T20260325_001, queries the session state node source, but the result is not found, and records fallbackReason=SESSION_MISS.

[0052] 2. The system builds cacheKey=trace:nodes:T20260325_001 and retrieves 47 nodes from the real-time cache at once.

[0053] 3. Perform integrity checks on 47 nodes to confirm that the nodes are not empty, the traceId is consistent, the traceNodeId exists, and the root node exists.

[0054] 4. Convert the 47 nodes into a Map.<traceNodeId, TraceNode> The target details node is accessed using nodeMap

[12] .

[0055] 5. The graph construction module generates nodes and edges based on the same nodeMap; the node details module directly reuses the nodeMap

[12] , without needing to query the database again.

[0056] The output results are shown in the following example (e.g.) Figure 5 (as shown)

[0057] Example 2: Persistent History Retrospection

[0058] Processing procedure: 1. Neither session state nor real-time cache was hit.

[0059] 2. Query persistent node records by traceId to obtain multiple primary keys in the form of traceId_traceNodeId.

[0060] 3. Split or restore the traceNodeId for each record.

[0061] 4. Write the recovered traceNodeId to the nodeMap.

[0062] 5. The graph and details still use nodeMap["1.remote"] to access the node, and the page logic is consistent with real-time Trace.

[0063] The technical means disclosed in this invention are not limited to those disclosed in the above embodiments, but also include technical solutions composed of any combination of the above technical features. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications are also considered within the scope of protection of this invention.

Claims

1. A trace backtracking method based on the collaborative reuse of session-state node sources and persistent node sources, characterized in that, Includes the following steps: S1. Session-state node source reading: Receive Trace backtracking request, the request including at least traceId and replay scene identifier; S2. Real-time cache node source reading: Construct a session key sessionKey = model- + traceId based on traceId, and query the set of trace nodes in the current session; If the query hits and the node set passes the integrity check, then the node set is used as a candidate node source. S3. Persistent Node Source Backtracking: If the session-state node source is not hit or fails the integrity check, then construct the real-time cache key trace:nodes:{traceId} based on traceId and query the real-time node cache. If the query hits and passes the integrity check, the set of real-time cache nodes will be used as the candidate node source. S4. Persistent Key Conversion: If both the session-state node source and the real-time cache node source are unavailable, or if the replay scenario requires historical tracing, then query the persistent node records in the form of traceId_traceNodeId and restore the persistent records to a set of TraceNode nodes; S5. Unified Node Mapping: Perform unified key processing on the candidate node set, writing each node into a Map using the traceNodeId as the runtime key.<traceNodeId, TraceNode> For persistent node records, the traceNodeId is first split or restored from the traceId_traceNodeId primary key. S6. Result Distribution: Distribute the Map...<traceNodeId, TraceNode> Write to the request context or replay context, and simultaneously provide it to the graph construction module, node details module, and snapshot viewing module for reuse; S7. Backtracking Source Identifier: Output backtracking results, which include at least nodeMap, sourceType, nodeCount, and fallbackReason.

2. The Trace backtracking method based on the collaborative reuse of session-state node sources and persistent node sources according to claim 1, characterized in that, In step S1, the set of trace nodes in the current session is queried based on sessionKey = "model-" + traceId; if a match is found and passes the integrity check, it is used as a candidate node source.

3. The Trace backtracking method based on the collaborative reuse of session-state node sources and persistent node sources according to claim 1, characterized in that, In step S2, when the session-state node source is not found or the verification fails, the component queries the real-time node cache based on cacheKey = "trace:nodes:" + traceId; if it is found and passes the integrity verification, it is used as a candidate node source.

4. The Trace backtracking method based on the collaborative reuse of session-state node sources and persistent node sources according to claim 1, characterized in that, In step S3, when both the session state and the real-time cache are unavailable, or when the replay scenario requires historical tracing, the persistent node records are queried in the form of traceId_traceNodeId and restored as a set of TraceNode nodes.

5. The Trace backtracking method based on the collaborative reuse of session-state node sources and persistent node sources according to claim 1, characterized in that, In step S4, the composite primary key in the persistent record is converted into a runtime traceNodeId.

6. The Trace backtracking method based on the collaborative reuse of session-state node sources and persistent node sources according to claim 1, characterized in that, In step S5, the set of nodes from any source is converted into a Map.<traceNodeId,TraceNode> If duplicate traceNodeIds are found, select records to retain based on source priority or update time, and record the reason for the conflict.

7. The Trace backtracking method based on the collaborative reuse of session-state node sources and persistent node sources according to claim 1, characterized in that, In step S6, the unified nodeMap is written into the request context or replay context and simultaneously provided to the graph construction module, node details module, and snapshot viewing module.

8. The Trace backtracking method based on the collaborative reuse of session-state node sources and persistent node sources according to claim 1, characterized in that, In step S7, the output sourceType, fallbackReason, and nodeCount are used to describe the path hit in this backtracking.

9. A trace backtracking system based on the collaborative reuse of session-state node sources and persistent node sources, characterized in that, include Session-state node source reading module: used to receive trace back requests, the requests including at least traceId and replay scene identifier; Real-time cache node source reading module: used to construct the session key sessionKey = model-+traceId based on traceId, and query the set of trace nodes in the current session; If the query hits and the node set passes the integrity check, then the node set is used as a candidate node source. Persistent node source backtracking module: If the session-state node source is not hit or fails the integrity check, it constructs a real-time cache key trace:nodes:{traceId} based on traceId and queries the real-time node cache. If the query hits and passes the integrity check, the set of real-time cache nodes will be used as the candidate node source. Persistent key conversion module: If both the session node source and the real-time cache node source are unavailable, or if the replay scenario requires historical tracing, then the persistent node record is queried in the form of traceId_traceNodeId, and the persistent record is restored to a set of TraceNode nodes; Unified Node Mapping Module: Used to perform unified key processing on the candidate node set, writing each node into a Map using traceNodeId as the runtime key.<traceNodeId, TraceNode> For persistent node records, the traceNodeId is first split or restored from the traceId_traceNodeId primary key. Result Distribution Module: Used to distribute Map results<traceNodeId, TraceNode> Write to the request context or replay context, and simultaneously provide it to the graph construction module, node details module, and snapshot viewing module for reuse; Backtracking source identifier module: used to output backtracking results, which include at least nodeMap, sourceType, nodeCount and fallbackReason.

Images