Request execution link data acquisition and processing method, electronic equipment and program product

Abstract

The invention provides a request execution link data acquisition and processing method, electronic equipment and a program product. The request execution link data acquisition method is applied to a data acquisition plug-in, and the data acquisition plug-in is synchronously started along with a monitored application; the method comprises the following steps: when a first execution event related to a request is monitored, creating a first execution node and recording execution information; when a follow-up execution event is monitored, creating a follow-up execution node, determining a previous execution node having a preorder calling relationship with the follow-up execution node as a father execution node, recording execution information of the follow-up execution node, and the follow-up execution node carrying a node identifier of the father execution node and a node identifier of the node; when the execution event is completed, the execution information of the corresponding node is updated; and when the request is processed, generating structured data representing a request execution link of the request in the monitored application based on the description information of the monitored application, all the execution nodes associated with the request and the corresponding execution information.

Description

Technical Field

[0001] This specification relates to the field of computer software technology, and in particular to a request execution link data acquisition method, a request execution link data processing method, an electronic device, and a computer program product. Background Technology

[0002] In the field of distributed system monitoring, tracing and analyzing request execution chains is crucial for system performance optimization and fault diagnosis.

[0003] Existing distributed tracing solutions typically employ a centralized data processing architecture. While these solutions can provide complete tracing capabilities, they have significant limitations in practical applications: First, such solutions usually rely on a series of heavy infrastructures such as large-scale message queues, stream processing platforms, and large data warehouses. Deploying and maintaining this entire system requires substantial computing, memory, and storage resources, resulting in huge resource consumption and high total cost of ownership. Second, the centralized collection and aggregation model is prone to creating data bottlenecks. Once system traffic surges, core processing nodes can easily become performance hotspots, leading to increased latency in tracing data or even data loss. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, a request execution chain data acquisition method is provided, applied to a data acquisition plugin, wherein the data acquisition plugin is started synchronously with the monitored application, and the data acquisition plugin is used to monitor multiple execution events related to the request processing process in the monitored application; the method includes: When the first execution event related to any request is detected, a first execution node carrying a node identifier is created for the request, and the execution information of the execution node is recorded; When a subsequent execution event related to the request is detected, a subsequent execution node associated with the request is created. The previous execution node that has a preceding call relationship with the subsequent execution node is determined as the parent execution node, and the execution information of the subsequent execution node is recorded. The subsequent execution node carries the node identifier of the parent execution node and the node identifier of this node. When any execution event related to the request is detected to be completed, the execution information of the corresponding execution node is improved. If the completion of the execution event indicates that the request has been processed, structured data representing the request execution chain in the monitored application is generated based on the description information of the monitored application, all execution nodes associated with the request and their corresponding execution information.

[0005] According to a second aspect of one or more embodiments of this specification, a request execution link data processing method is provided, comprising: Obtain structured data representing the request execution chain in the monitored application, the structured data being generated by the method described in the first aspect; Based on pre-stored application metadata and database metadata, the structured data is parsed into multiple data records in a unified data format, with each data record corresponding to an execution node; The data record contains specialized parsing content, which is determined based on the functional level type of the execution node: if the functional level type of the execution node is a network interface request type, the specialized parsing content includes detailed network interface request information obtained from the parsing; if the functional level type of the execution node is a database access type, the specialized parsing content includes detailed database access information obtained from the parsing.

[0006] According to a third aspect of one or more embodiments of this specification, a request execution link data processing method is provided, comprising: Obtain structured data representing the request execution chain in the monitored application, the structured data being generated by the method described in the first aspect; Based on the execution nodes in the structured data, topological nodes are generated, and based on the node identifiers of the parent execution nodes and the node identifiers of the current node carried by the execution nodes, topological edges representing the calling relationships between execution nodes are constructed. A topology graph structure is constructed based on the topology nodes and topology edges, and synchronously sent to the topology event processing service to generate an inter-service lineage graph. According to a fourth aspect of the embodiments of this specification, an electronic device is provided, comprising: processor; Memory used to store processor-executable instructions; Wherein, when the processor executes the executable instructions, it is used to implement the method described in the first aspect, the second aspect, or the third aspect.

[0007] According to a fifth aspect of the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps of the method described in the first, second, or third aspect.

[0008] According to a sixth aspect of the embodiments of this specification, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the first, second, or third aspect.

[0009] As can be seen from the above embodiments, this specification enables on-demand allocation and use of resources by starting the data acquisition plugin synchronously with the monitored application and independently completing the collection and structured encapsulation of request execution link data locally. This allows for rapid deployment without heavy infrastructure, providing good versatility and lightweight deployment capabilities, and effectively reducing costs.

[0010] Furthermore, the data acquisition plugin constructs execution nodes for requests by detecting the occurrence of execution events and identifies parent execution nodes according to the preceding call relationship. This ensures that the final generated request execution chain data has an accurate causal order and a clear call hierarchy, thereby accurately reconstructing the request execution flow. Finally, after the request is completed in the monitored application, the application's description information, along with all execution nodes and their corresponding execution information, are integrated locally. The resulting structured data completely encapsulates the complete execution context of a request within a single application, providing a high-quality data foundation for downstream processing systems.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of a data acquisition architecture provided in an exemplary embodiment.

[0013] Figure 2 This is a flowchart of a request execution link data acquisition method provided in an exemplary embodiment.

[0014] Figure 3 This is a schematic diagram illustrating a data format for structured data provided in an exemplary embodiment.

[0015] Figure 4 This is an exemplary embodiment of a schematic diagram illustrating the collection, processing, and application of structured data representing a request execution chain in a monitored application.

[0016] Figure 5 This is a flowchart of a request execution link data processing method provided in an exemplary embodiment.

[0017] Figure 6 This is a schematic diagram illustrating a data format for a data record provided in an exemplary embodiment.

[0018] Figure 7 This is a flowchart of another request execution link data processing method provided in an exemplary embodiment.

[0019] Figure 8 This is a schematic diagram of the complete call path for a request provided in an exemplary embodiment.

[0020] Figure 9 This is a schematic diagram of the structure of a device provided in an exemplary embodiment. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0022] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals shall be provided for users to choose to authorize or refuse.

[0023] Please see Figure 1 To avoid the huge resource consumption caused by maintaining a large computing cluster for processing massive amounts of data year-round under a centralized architecture, the embodiments in this specification adopt an on-demand deployment mode, independently deploying the corresponding data acquisition plugin 20 for any monitored application 10, so that the request execution link data is built and processed locally on the application side, thereby achieving lightweight deployment.

[0024] The data acquisition plugin 20 described in this specification is an independent software component that starts synchronously with the monitored application, and the data acquisition plugin 20 and the monitored application 10 run independently. The data acquisition plugin 20 monitors multiple execution events related to the request processing process in the monitored application 10 using non-intrusive technologies such as bytecode enhancement.

[0025] For example, bytecode enhancement can be implemented based on the ASM bytecode manipulation framework: When the data acquisition plugin starts, it scans the core classes related to request processing in the monitored application using ASM, such as Controller and Service layer classes, and parses their bytecode structure. Customized enhancement code is inserted at the method entry / exit points corresponding to execution events such as request reception, method invocation, and response return. For example, code is inserted at the request processing method entry point to trigger the creation of the first execution node and record initial information such as node identifier and execution time; code is inserted at the method invocation point to identify the preceding call relationship and associate it with the parent execution node; and code is inserted at the method exit point to complete the execution node's time consumption, status, and other information. The entire process requires no modification to the application source code; precise monitoring of execution events is achieved solely through non-intrusive enhancement at the bytecode level.

[0026] Typically, a request within the monitored application 10 triggers the execution of one or more logical stages or code snippets. Each logical stage or code snippet can be abstracted as an "execution event." Different execution events have a defined sequence and dependencies; for example, the execution of an internal method depends on the triggering of upstream controller logic. The data acquisition plugin 20 can capture these execution events with fine granularity and build an execution node for each event, while recording relevant runtime information, such as timestamps, thread identifiers, event types, dependencies, and other structured data. By managing the execution nodes and their dependencies locally, and combining this with the description information of the monitored application 10 (such as application identifier, version number, deployment environment, etc.), the data acquisition plugin 20 can automatically generate structured data locally at the end of request execution. This structured data accurately represents the request execution chain within the current application, for subsequent analysis, visualization, or diagnosis.

[0027] In some scenarios, considering that some requests may be processed across multiple applications in actual scenarios, in order to ensure the consistency of cross-application link tracing, this embodiment of the specification further includes a data acquisition and scheduling platform 30, as shown in Figure 1. The data acquisition and scheduling platform 30 is used to coordinate the acquisition, propagation, and merging of link context when different applications participate in link construction. When the data acquisition plugin 20 detects the first execution event of a request, it can actively interact with the data acquisition and scheduling platform 30 to determine whether the request has already carried the link context generated by the upstream application, and generate or inherit the link identifier and parent node identifier for the current link accordingly.

[0028] When a request initiates an external call from the current application to a downstream application, the data acquisition plugin 20 can generate a link context that can be used for cross-application transmission based on the current link identifier, the node identifier of the external call event, and the description information of the called application. This context is then distributed by the acquisition scheduling platform 30 to the corresponding data acquisition plugin 20 responsible for monitoring the called application. In this way, in scenarios where multiple applications collaboratively process the same request, the link structure can be completely inherited and extended across multiple applications, thereby ensuring that the entire request execution link maintains global consistency and traceability within the distributed system.

[0029] Through the above mechanism, the embodiments of this specification can construct an accurate, complete, and mergeable execution link for each request without relying on centralized data aggregation and real-time processing, thereby achieving a highly reliable and low-overhead link acquisition capability for distributed systems.

[0030] The following provides an exemplary description of the request execution link data acquisition method provided in the embodiments of this specification: Please refer to Figure 2 This diagram illustrates a flowchart of a request execution chain data acquisition method. This method is applied to a data acquisition plugin, which starts synchronously with the monitored application. The data acquisition plugin is used to monitor multiple execution events related to the request processing process in the monitored application. For example, the multiple execution events monitored by the data acquisition plugin include, but are not limited to: service request processing events, database query events, and external call events.

[0031] Service request processing events refer to the logical operations performed internally by the application after receiving an external request. These events typically correspond to the entry point of the request into the application, such as HTTP API calls, RPC requests, or message queue message consumption. When such an event occurs, the data collection plugin creates the first execution node, recording execution information such as the request's entry point, request type, request parameters, and start time.

[0032] Database query events refer to any database interaction-related operations performed by an application during request processing, such as SQL queries, updates, inserts, or deletes. Each database operation is considered an independent execution event, and the data acquisition plugin creates a corresponding execution node for it, recording execution information such as the query statement, execution start time, execution time, and execution results or exception information.

[0033] External call events refer to requests initiated by an application to other applications while processing other requests, such as calls to microservice interfaces, third-party APIs, or remote RPC services. The data collection plugin creates a corresponding execution node for each external call, recording the call target, call start time, call parameters, call duration, and return results or exception information. If the external call involves a cross-application chain, the data collection plugin also generates a chain context and interacts with the scheduling platform to ensure the continuation of the cross-application request chain.

[0034] For example, in addition to the service request processing events, database query events, and external call events mentioned above, the data acquisition plugin can also monitor other types of execution events as needed by the actual application scenario, such as cache access events, message queue message sending / receiving events, file read / write events, scheduled task execution events, or custom method execution events. The embodiments in this specification do not limit the types of execution events monitored; that is, the execution events listed above are merely illustrative examples. The data acquisition plugin can flexibly expand the types of events monitored according to the needs of different applications to ensure comprehensive perception and accurate recording of the request execution chain.

[0035] Please see Figure 2 The requested execution of link data collection methods includes: In S200, when the first execution event related to any request is detected, a first execution node carrying a node identifier is created for the request, and the execution information of the execution node is recorded.

[0036] For example, the first execution event could be the service request processing event mentioned above. The service request processing event typically serves as the starting point for a request to enter the application's internal logic and is one of the key event types when constructing the request execution chain. This event is usually triggered by the application framework's entry layer, such as HTTP request reception in a web service, RPC call entry point in a microservice architecture, or message consumption entry point driven by message middleware. When this event occurs, the application begins executing a series of processing logics for that request. Therefore, by using the service request processing event as the first execution event, the initial state of the request's lifecycle within the application can be accurately captured, providing a clear location for subsequent execution nodes and making the hierarchical structure of the entire chain more explicit.

[0037] The execution information recorded in the first execution node includes, but is not limited to: start time, request type, request parameters, request source information, thread or process identifier, and application instance information.

[0038] For example, in a real-world distributed system, requests may not always originate within the current application, but could come from other upstream applications. To ensure accurate tracking of the entire multi-application distributed request chain, it is necessary to collaborate with the data acquisition and scheduling platform when the first execution event occurs. That is, when the first execution event related to any request is detected, the data acquisition plugin can also interact with the data acquisition and scheduling platform to determine if a first link context corresponding to that request exists.

[0039] If the first link context is obtained from the data collection and scheduling platform, it means that the request is already part of the cross-application link. The data collection plugin then obtains the link identifier of the request execution link and the node identifier of the parent execution node of the first execution node from the first link context. The link identifier is used to maintain a unified numbering throughout the distributed link, while the parent execution node identifier is used to correctly attach the first execution node of the current application to the execution node of the upstream application in the local link, forming a complete cross-application call tree. This ensures that the link tracing system can obtain a consistent and hierarchical request link structure from the upstream to the downstream.

[0040] If the data acquisition and scheduling platform returns an indication that a first link context does not exist, it means that the request only enters the entire system from the current application. In this case, the data acquisition plugin creates a unique link identifier for the request execution link, serving as the root identifier for the request in the distributed link system. Simultaneously, since there are no upstream dependencies, the data acquisition plugin also sets the parent execution node of the first execution node to null.

[0041] The aforementioned interaction mechanism ensures the uniqueness and end-to-end integrity of the data collection process, preventing link breaks or duplication due to independent data collection by upstream and downstream applications. Furthermore, the responsibility for cross-application link management is delegated to the data collection and scheduling platform, allowing data collection plugins deployed on the application side to focus solely on event collection and execution node construction, thereby reducing development and maintenance burdens.

[0042] In S202, when a subsequent execution event related to the request is detected, a subsequent execution node associated with the request is created. The previous execution node that has a preceding call relationship with the subsequent execution node is determined as the parent execution node, and the execution information of the subsequent execution node is recorded. The subsequent execution node carries the node identifier of the parent execution node and the node identifier of this node.

[0043] Scenarios requiring the continuation of subsequent execution events include, but are not limited to: requests that cannot be completed in one go within the current application, requests that rely on query results from the underlying database, requests that call external applications, requests that access caching systems, requests that send synchronous or asynchronous messages, or requests that require processing by multiple intermediate logic modules. Any new logical stage or code snippet triggered during the execution of a request can be considered a subsequent execution event.

[0044] For example, subsequent execution events may include database query events and / or external call events. For instance, when an application needs to read data from a database during request processing, a database query event will be triggered. The data acquisition plugin will create a corresponding execution node at the start of the database query operation and complete the execution information of that node after the database returns the results. Similarly, when an application needs to delegate some processing logic to other applications, an external call event will be triggered. In this case, the data acquisition plugin will also record the start and end points of the external call event and create an execution node for the external call.

[0045] Subsequent execution events accurately reflect the complete execution path of the request within the application. When a new subsequent execution event is detected, the data acquisition plugin needs to identify its preceding execution event—that is, the execution node that triggered the current execution event—to maintain the correct parent-child relationship in the chain structure. This embodiment achieves a structured association between execution nodes by automatically identifying the preceding call relationship and setting the previous execution node as the parent execution node. Each subsequent execution node carries its own identifier and the identifier of its parent execution node, which not only ensures the orderliness of the chain but also enables the accurate reconstruction of the chain's hierarchical relationship.

[0046] In one possible implementation, when the detected subsequent execution event is an external call event, the data acquisition plugin not only creates an execution node corresponding to the event and records relevant execution information, but also generates a second link context for cross-application propagation based on the link identifier of the request execution link, the node identifier of the execution node corresponding to the external call event, and the description information of the called application. The link identifier can serve as a global association marker across applications, and the node identifier of the execution node corresponding to the external call event can serve as the parent node identifier of the subsequent link, thereby ensuring that the link structure remains clear in hierarchy and causal relationship in a multi-application environment.

[0047] Subsequently, the data acquisition plugin pushes the generated second link context to the acquisition scheduling platform, enabling the platform to distribute this context to the data acquisition plugins responsible for monitoring the called applications. Thus, when the called application begins processing the external call request, its local data acquisition plugin can obtain the cross-application propagated second link context from the acquisition scheduling platform. Based on the link identifier and node identifier within this context, it can then correctly connect and create a new execution node structure on its own side. Through this cross-application propagation mechanism, seamless splicing of link tracing data between different applications can be achieved, ensuring the continuity and observability of the entire call chain even in scenarios involving multiple systems and components operating collaboratively.

[0048] In S204, when any execution event related to the request is detected to be completed, the execution information of the corresponding execution node is improved. If the completion of the execution event indicates that the request has been processed, structured data representing the request execution chain in the monitored application is generated based on the description information of the monitored application, all execution nodes associated with the request and their corresponding execution information.

[0049] In this step, when the termination of an execution event (whether it's service request processing, database query, or external call) is captured, the data acquisition plugin locates the execution node corresponding to that event, i.e., the previously created execution node, and then supplements the termination information of that execution node. The supplemented information typically includes, but is not limited to: ① End timestamp: Recording the exact time the execution node completed for subsequent calculation of its execution duration. ② Execution status: Indicating whether the node completed successfully or encountered an exception. If an exception occurred, it is marked as an error. ③ Exception details (if any): If the execution event throws an exception or error, the plugin also collects details such as the exception type, stack trace, and error message for subsequent analysis. ④ Returned or result data (optional): For database queries, it may record the number of rows returned or the response size; for external calls, it may record the return status code, response body summary (such as small JSON tags), etc. ⑤ Resource usage metrics (if configurable): In some implementations, it can also record metrics such as CPU consumption, peak memory usage, and network latency of the execution node to support more accurate performance profiling. These records further complete the execution information of the execution nodes, thus accurately reflecting the details of each logical stage or invocation stage.

[0050] After completing the information for a single execution node, the data acquisition plugin also determines whether the completion of the execution event signifies that the entire request has been processed. Typically, the determination of "request completion" is based on detecting the endpoint of the corresponding entry point (i.e., the first execution event), such as an HTTP response or the end of an RPC response. If the request is confirmed to be complete, the data acquisition plugin initiates a link encapsulation process: the plugin aggregates the description information of the monitored application, all execution nodes associated with the request, and their corresponding execution information, and then encapsulates this into structured data representing the request execution link within the monitored application. This structured data is usually represented in a preset format. By aggregating all execution nodes, the structured data accurately reflects the complete path of a request from entry point to completion, including each call or query stage, thereby supporting precise performance analysis and fault location.

[0051] The request execution chain data collection method provided in this embodiment firstly, by synchronously starting the data collection plugin with the monitored application, the data collection plugin can run continuously and stably throughout the application's lifecycle without the need for additional service governance frameworks or centralized proxies, thus significantly reducing deployment complexity and operational barriers. The data collection plugin independently completes local data collection, node construction, and chain encapsulation, enabling on-demand use and immediate recycling of computing and storage resources. It is suitable for resource-sensitive platforms such as microservice architectures, containerized environments, serverless computing scenarios, and edge nodes, possessing good versatility and lightweight deployment capabilities. Secondly, the data collection plugin constructs execution nodes for requests based on an event-driven approach and identifies parent execution nodes according to the preceding call relationship, ensuring that the final generated request execution chain has an accurate causal order and a clear call hierarchy, thereby accurately reconstructing the request execution flow.

[0052] The format of the structured data used to represent the request execution chain is preset but configurable, allowing downstream services to parse and process it according to their own needs. For an example, please refer to [link to example]. Figure 3 The structured data mentioned above includes the link identifier of the request execution link, the description information of the monitored application, the destination terminal identifier of the request, all execution nodes associated with the request, and the corresponding execution information.

[0053] The description information of the monitored application includes at least one of the following: the application identifier of the monitored application, the name of the service provided by the monitored application, and the instance identifier of the service provided by the monitored application, but is not limited to these.

[0054] All execution nodes associated with the request and their corresponding execution information are organized in the structured data as a list of execution nodes. The list items corresponding to each execution node in the execution node list include: the node identifier of the parent execution node, the node identifier of the current node, and the execution information.

[0055] The execution information of any execution node includes at least one of the following: ① Timestamp information: including start and end times, used to describe the time segment in which the node is executed, and can be used to calculate execution time and identify performance bottlenecks.

[0056] ② Operation description information: Records reference information, operation name and actual operation object, etc., used to identify the processing operation corresponding to the node, such as interface path, access target, query statement summary, etc.

[0057] ③ Execution status information: Records the final execution result of the node, key attributes and important events in the process, which is the fundamental basis for error diagnosis. For example, it includes error identifiers, label lists and event logs.

[0058] ④ Classification Information: This includes node type and functional level type. Specifically, the functional level type of execution nodes includes network interface request type and database access type. Execution nodes corresponding to service request processing events and external call events belong to the network interface request type, while execution nodes corresponding to database query events belong to the database access type.

[0059] For example, the data collection plugin can automatically determine the type of execution event through a preset feature matching mechanism. For instance, it can construct identification rules based on the method features (annotations, class paths, method name keywords) obtained during bytecode enhancement, including two types of features and matching logic: (1) Network interface request type features: such as Controller layer annotations (@RequestMapping / @PostMapping), fully qualified names of external calling classes (e.g., feign.Client, org.apache.http.client.HttpClient), and service entry method name keywords (doService / handleRequest); (2) Database access type features: such as database operation class names (e.g., java.sql.PreparedStatement, org.mybatis.spring.SqlSessionTemplate), Mapper interface annotations (@Mapper), and SQL execution method names (e.g., query / update / select). During matching, the data collection plugin obtains the method meta-information (annotations, class names, method names) corresponding to the execution event through bytecode enhancement, compares it with the features in the rule base one by one, and determines the corresponding type by matching any feature. The entire process is completed automatically, without intrusion and with high accuracy. In some implementations, please refer to Figure 4After the data acquisition plugin generates structured data representing the request execution chain in the monitored application, it can further encapsulate this structured data into a message and send it to a preset message queue. Subsequent consumer components can then acquire and process this data according to their processing capabilities and consumption strategies. For example, the data acquisition plugin can first serialize the structured data into a JSON string to obtain a data representation with good cross-language and cross-platform readability. Then, it converts the JSON string into a byte array according to a predetermined character encoding (such as UTF-8). The resulting byte array can be encapsulated as a message object. During the sending to the message queue, the message object automatically completes serialization processing according to the message system's protocol (e.g., a binary-based efficient transmission format). This ensures that the message maintains its field structure and byte order during transmission between heterogeneous operating environments, guaranteeing the integrity, resolvability, and security of the link data in the distributed system.

[0060] In some embodiments, please refer to Figure 4 as well as Figure 5 This specification also provides a request execution link data processing method, applied to a link processing platform capable of parsing, transforming, and integrating request execution link data. For example, the link processing platform may pre-store application metadata and database metadata, such as lineage services, but is not limited thereto. The link processing platform can continuously pull messages sent by the data acquisition plugin from the message queue, decode the messages to obtain structured data, and further convert the structured data into a unified data format that meets downstream analysis, tracking, statistical, or visualization needs. The method includes: In S500, structured data is acquired to represent the request execution chain in the monitored application.

[0061] For example, the link processing platform, acting as a consumer, can retrieve messages from a specified message queue, and then deserialize the messages to recover structured data representing the request execution link in the monitored application. This structured data includes the link identifier of the request execution link, the description information of the monitored application, multiple execution nodes, and corresponding execution information.

[0062] In S502, based on pre-stored application metadata and database metadata, structured data is parsed into multiple data records in a unified data format, with each data record corresponding to an execution node.

[0063] For example, a link processing platform typically maintains application metadata and database metadata, such as: application identifier → application name, responsible person, and module; interface path → service and interface category; database name → data source type, database name, table name, and field definition.

[0064] Pre-stored application metadata and database metadata can play a role in data enhancement and semantic supplementation. The link processing platform supplements the execution node with its complete context information in the technical architecture by associating and mapping these metadata with the above-mentioned structured data. This includes, but is not limited to: (1) using application metadata to associate technical application identifiers with application technical attributes, such as mapping application identifiers to the application's technical name, the deployment cluster or resource pool to which it belongs, and its level or functional group in the system architecture. (2) using database metadata to enrich the basic connection information in the database access node into a complete data source technical profile, such as mapping the database name to the data source type, the specific database name and table name, and the table structure definition.

[0065] Through this metadata-driven parsing process, execution nodes in the original chain are endowed with rich technical semantics. For example, a database access node no longer simply records "an SQL query was executed," but can explicitly identify that "a query was performed in the order database user table of the MySQL production cluster"; an external service call node no longer simply records "a certain URL was called," but can explicitly identify that "the user service's authentication interface was called via the HTTPS protocol." This deep enhancement of technical context provides an accurate and complete information foundation for subsequent data analysis, architecture governance, and operation and maintenance management.

[0066] For each execution node in the structured data, the link processing platform can generate a data record with a unified data format through the parsing process described above. Please refer to [link to relevant documentation]. Figure 6 Each data record includes, but is not limited to: the link identifier of the request execution chain, the node identifier of the parent execution node, the node identifier of this node, timestamp information, operation description information, execution status information, classification information, and special parsing content. For information such as timestamp information, operation description information, execution status information, and classification information, please refer to the above description, which will not be repeated here.

[0067] The specific parsing content contained in the data record corresponding to each execution node is determined based on the functional level type of that execution node: if the functional level type of the execution node is a network interface request type, the specific parsing content includes the parsed network interface request details; if the functional level type of the execution node is a database access type, the specific parsing content includes the parsed database access details.

[0068] For example, database access details include, but are not limited to, at least one of the following: client port, server IP, server port, database name, database type, SQL character set, database user, SQL statement, execution result, number of rows affected, reception time, response time, hexadecimal SQL, and database schema name.

[0069] For example, the detailed information of a network interface request includes, but is not limited to, at least one of the following: request address, request method, request parameters, request body, request status code, request header, user information, return value, client IP, start time, end time, parsed request body, parsed query parameters, parsed request header, and sensitive identification result of return value, etc.

[0070] This embodiment transforms raw structured data into standardized data records that are rich in technical semantics, structurally unified, and informationally complete through metadata-driven and unified format conversion. This provides a high-quality, easily consumable data foundation for diverse downstream processing services (such as real-time risk identification, data asset discovery, and service popularity statistics).

[0071] In some embodiments, please refer to Figure 4 The link processing platform can classify and route data records based on the functional level type of the execution node: data records with the functional level type of network interface request are encapsulated into a first type of message and synchronously sent to a first message queue for risk identification by the network request risk alarm service; and data records with the functional level type of database access are encapsulated into a second type of message and synchronously sent to a second message queue for risk identification by the database risk alarm service.

[0072] For example, the link processing platform can first convert each data record into a JSON string, and then encode the JSON string into a byte array. This step achieves a standardized conversion of data from object format to a common transmission format. Next, the byte array is encapsulated into a message (either a first-type message or a second-type message). Before being sent to the corresponding message queue (either a first-type message queue or a second-type message queue), the first-type message or the second-type message will be serialized into a binary protocol format according to the protocol requirements of the corresponding message queue, ensuring transmission efficiency and reliability. The link processing platform, acting as a producer, synchronously sends the encapsulated first-type message and second-type message to different message queues. This synchronization mechanism guarantees the real-time and sequential nature of data transmission.

[0073] This embodiment achieves separation of concerns by routing two different types of data—network requests and database accesses—to different message queues and dedicated risk alert services. Each risk alert service can be independently expanded and optimized, focusing on handling specific types of security threats, thus improving the accuracy of risk identification and processing efficiency. Furthermore, the use of a synchronous sending mode combined with the persistence mechanism of the message queue ensures that critical monitoring data can be delivered to downstream processing systems in a timely and reliable manner, meeting the needs of scenarios requiring real-time risk detection and response.

[0074] In other embodiments, please refer to Figure 4 Electronic devices can encapsulate data records according to the storage format of the target database, form storage records, and persist them to the target database for asynchronous use by downstream services; the storage record contains complete information about the execution node.

[0075] Among them, the downstream service runs an asynchronous query task with a timed polling mechanism to periodically query the storage records stored in the target repository within a specified time window, and execute the corresponding task based on the queried storage records.

[0076] For example, downstream services include a data asset discovery service, which analyzes the queried storage records, identifies newly emerging application services or interface endpoints, registers these newly discovered assets to the lineage service, and can further display the identification results.

[0077] For example, downstream services include a popularity statistics service. The popularity statistics service analyzes the application call relationships and interface access frequencies in the queried storage records, updates the corresponding statistical indicators, provides data support for system operation status monitoring and service dependency analysis, and can also display statistical results.

[0078] This embodiment utilizes an asynchronous persistence mechanism to ensure the complete preservation of link information through persistent data storage, providing a stable and reliable data source for downstream services. This mechanism guarantees no data loss and meets the requirements for data reliability. It can simultaneously support multiple application scenarios such as trend analysis, anomaly backtracking, and asset discovery. This data application model of "collect once, use multiple times" significantly improves data utilization efficiency and reduces system complexity.

[0079] In some embodiments, please refer to Figure 7 This specification also provides a request execution link data processing method, applied to a link processing platform capable of parsing, transforming, and integrating request execution link data. The method includes: In S700, structured data is acquired to represent the request execution chain in the monitored application.

[0080] For example, the link processing platform, acting as a consumer, can retrieve messages from a specified message queue, and then deserialize the messages to recover structured data representing the request execution link in the monitored application. This structured data includes the link identifier of the request execution link, the description information of the monitored application, multiple execution nodes, and corresponding execution information.

[0081] In S702, topological nodes are generated based on the execution nodes in the structured data, and topological edges representing the calling relationships between execution nodes are constructed based on the node identifiers of the parent execution node and the node identifier of the current node carried by the execution node.

[0082] For example, the link processing platform can parse key attributes of each execution node from structured data, including application identifier, service name, node type, and node parameters (such as interface path, database name, etc.), and construct topology nodes based on these attributes. Each topology node uniquely identifies a technical component in the system. Furthermore, the link processing platform can construct topology edges representing call relationships based on the node identifier of the execution node and the node identifier of its parent execution node. By analyzing the parent-child relationship chain between execution nodes, it can accurately reconstruct the actual call path of the request in the distributed system, forming directed edges from the source node to the target node.

[0083] In S604, a topology graph structure is constructed based on topology nodes and topology edges, and is synchronously sent to the topology event processing service to generate a lineage graph between services.

[0084] For example, the link processing platform combines the generated topology nodes and edges to construct a complete topology graph structure. This graph structure accurately reflects the calling relationships and dependency structure between various components in the distributed system. Subsequently, the constructed topology graph is encapsulated as topology events and sent synchronously to the topology event processing service. This synchronization mechanism ensures that topology information can be transmitted to downstream processing systems in real time.

[0085] For example, suppose in a request execution chain, after a user initiates a request, it goes through application A, application B, and accesses database A and database B. Then, the data collection plugin of application A can collect structured data 'a' representing the request execution chain in application A, and the data collection plugin of application B can collect structured data 'b' representing the request execution chain in application B.

[0086] The structured data 'a' contains information about all execution nodes for this request in application A, including: execution nodes representing application A's own services, execution nodes representing access to database A, and execution nodes representing calls to application B.

[0087] Based on structured data a, the following topological elements can be generated: (1) Topological nodes: application A node, database A node, application B node; (2) Topological edges: application A node → database A node (indicating application A accesses database A); application A node → application B node (indicating application A calls application B). Topological graph A can be generated: application A → application B; application A → database A.

[0088] The structured data b contains information about all execution nodes for this request in application B, including: execution nodes representing the services of application B itself, and execution nodes representing access to database B.

[0089] Based on structured data b, the following topological elements can be generated: (1) Topological nodes: application B node, database B node; (2) Topological edges: application B node → database B node (indicating application B accessing database B). A topological graph B can be generated: application B → database B.

[0090] After receiving topology graphs A and B, the topology event handling service can obtain the following based on the user request entry point, topology graph A, and topology graph B: Figure 8 The diagram shows the directed topology graph structure. This graph clearly illustrates the complete call path of a request: User request entry point: user → Application A; Inter-application call chain: Application A → Application B; Data access relationship: Application A → Database A; Application B → Database B.

[0091] This topology construction approach, which involves collecting data from different applications and combining them uniformly, ensures that in complex distributed system environments, each application only needs to focus on its own execution context. Ultimately, a unified topology processing service integrates the data to create a global system architecture view, providing an accurate and complete dependency data foundation for system monitoring, troubleshooting, and architecture optimization.

[0092] In some exemplary application scenarios, the aforementioned request execution link data processing method can be directly applied to a security risk control system to build a high-real-time, high-precision, and continuously evolving risk identification and prevention capability. After the link processing platform parses and converts the structured link data from the data acquisition plugin into unified data records, various downstream security risk control services can conduct corresponding risk identification and security analysis based on this data, thereby achieving full-link security supervision of the distributed system.

[0093] For example, the network request risk alert service can analyze request sources, request parameters, request body content, return results, and abnormal patterns in real time based on data records belonging to network interface request types in the execution node. Leveraging the interface call chain information provided by the link processing platform, this service can not only identify abnormal single-point interface behavior but also discover potential attack patterns based on the combined behavior of multiple interfaces in the call chain, such as recursive call abuse and malicious parameter injection, thereby improving the accuracy of threat detection.

[0094] The database risk alert service can monitor SQL access patterns, access frequency, changes in the number of data rows, and table-level or field-level access characteristics based on data records of database access types, thereby identifying high-risk actions such as unauthorized access, scanning of a large number of sensitive fields, and potential data leakage.

[0095] The data asset discovery service relies on the call paths and resource access information continuously accumulated in the link data to automatically identify newly launched applications, interface endpoints, database resources and other technical assets, realize automated asset registration, avoid missing key components, and provide a complete asset baseline for security governance.

[0096] The popularity statistics service can perform real-time statistics on the access popularity of resources such as applications, interfaces, and database tables based on the call relationships and access frequency information provided by the link processing platform. Security teams can use this to identify hot resources or abnormal access fluctuations, thereby further locating potential risks or performance bottlenecks.

[0097] The topology event handling service builds a system-level call topology graph based on multiple request links. It can be used to identify critical paths, core dependencies, and weak nodes on the links, assisting security teams in building more reliable protection strategies and forming a visualized system security view.

[0098] In summary, these downstream risk control services provide more refined and intelligent security protection capabilities for distributed systems by sharing the unified data structure and topology information provided by the link processing platform.

[0099] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0100] Figure 9 This is a schematic structural diagram of a device provided in an exemplary embodiment. For example... Figure 9As shown, device 900 mainly consists of a communication interface 902, a user interface 904, a processor 906, and a data storage 908. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 910. The communication interface 902 enables device 900 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 902 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 902 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 902 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 902 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0101] User interface 904 includes receiving user input and providing output to the user. Therefore, user interface 904 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 904 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 904 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 900 may support remote access from other devices via communication interface 902 or another physical interface (not shown). User interface 904 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 904 may also be configured as a display device for rendering or displaying text fragments.

[0102] Processor 906 may contain one or more general-purpose processors and / or special-purpose processors.

[0103] Data storage 908 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 906. Data storage 908 may include removable and non-removable components.

[0104] Processor 906 is capable of executing program instructions 918 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 908 to perform the various functions described herein. Data storage 908 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 900, enable device 900 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 906 executing program instructions 918 may result in processor 906 using data 912.

[0105] For example, program instructions 918 may include an operating system 922 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 900 and one or more application programs 920 (e.g., a browser, social media application, or game application). Similarly, data 912 may include operating system data 916 and application data 914. Operating system data 916 is primarily accessible to the operating system 922, while application data 914 is primarily accessible to one or more application programs 920. Application data 914 may reside in a file system visible or hidden from the user of device 900.

[0106] Application 920 can communicate with operating system 922 through one or more application programming interfaces (APIs). These APIs help application 920 read and / or write application data 914, transmit or receive information via communication interface 902, receive or display information on user interface 904, etc.

[0107] In some terminology, application 920 may be simply referred to as "app". Furthermore, application 920 can be downloaded to device 900 through one or more online app stores or app markets. However, applications can also be installed on device 900 in other ways, such as through a web browser or a physical interface on device 900 (e.g., a USB port).

[0108] In some embodiments, the request execution link data acquisition device can be applied to, for example... Figure 9 The device shown implements the technical solution described in this specification. It is applied to a data acquisition plugin, which starts synchronously with the monitored application. The data acquisition plugin is used to monitor multiple execution events related to the request processing process in the monitored application. The request execution chain data acquisition device may include: The execution node creation module is used to create a first execution node carrying a node identifier for the request when the first execution event related to any request is detected, and to record the execution information of the execution node; The execution node creation module is also used to create a subsequent execution node associated with the request when a subsequent execution event related to the request is detected, determine the previous execution node that has a preceding call relationship with the subsequent execution node as the parent execution node, and record the execution information of the subsequent execution node. The subsequent execution node carries the node identifier of the parent execution node and the node identifier of this node. The execution node improvement module is used to improve the execution information of the corresponding execution node when any execution event related to the request is detected to be completed, and, if the completion of the execution event indicates that the request has been processed, generate structured data representing the request execution chain in the monitored application based on the description information of the monitored application, all execution nodes associated with the request and their corresponding execution information.

[0109] In some embodiments, the request execution link data processing device can be applied to, for example... Figure 9 The device shown is used to implement the technical solution of this specification. The device includes: The structured data acquisition module is used to acquire structured data representing the request execution chain in the monitored application, the structured data being generated by the aforementioned acquisition device.

[0110] The parsing module is used to parse the structured data into multiple data records in a unified data format based on pre-stored application metadata and database metadata. Each data record corresponds to an execution node. The data records contain specific parsing content, which is determined based on the functional level type of the execution node: if the functional level type of the execution node is a network interface request type, the specific parsing content includes detailed network interface request information; if the functional level type of the execution node is a database access type, the specific parsing content includes detailed database access information.

[0111] In some embodiments, the request execution link data processing device can be applied to, for example... Figure 9 The device shown is used to implement the technical solution of this specification. The device includes: The structured data acquisition module is used to acquire structured data representing the request execution chain in the monitored application, the structured data being generated by the aforementioned acquisition device.

[0112] The topology information generation module is used to generate topology nodes based on the execution nodes in the structured data, and to construct topology edges representing the calling relationships between execution nodes based on the node identifiers of the parent execution nodes and the node identifiers of the current node carried by the execution nodes.

[0113] The topology information generation module is also used to construct a topology graph structure based on the topology nodes and topology edges, and synchronously send it to the topology event processing service to generate a lineage graph.

[0114] For more detailed descriptions of the devices, please refer to the descriptions of the corresponding methods above, which will not be repeated here. For ease of description, the above devices are described by function as various modules or units. Of course, when implementing one or more of this specification, the functions of each module or unit can be implemented in one or more software and / or hardware, or a module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0115] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0116] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0117] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0118] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0119] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0120] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0121] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0122] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0123] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0124] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. A method for collecting request execution chain data, applied to a data collection plugin, wherein the data collection plugin starts synchronously with the monitored application, and the data collection plugin is used to monitor multiple execution events related to the request processing process in the monitored application; the method includes: When the first execution event related to any request is detected, a first execution node carrying a node identifier is created for the request, and the execution information of the execution node is recorded; When a subsequent execution event related to the request is detected, a subsequent execution node associated with the request is created. The previous execution node that has a preceding call relationship with the subsequent execution node is determined as the parent execution node, and the execution information of the subsequent execution node is recorded. The subsequent execution node carries the node identifier of the parent execution node and the node identifier of this node. When any execution event related to the request is detected to be completed, the execution information of the corresponding execution node is improved. If the completion of the execution event indicates that the request has been processed, structured data representing the request execution chain in the monitored application is generated based on the description information of the monitored application, all execution nodes associated with the request and their corresponding execution information.

2. The method according to claim 1, further comprising: When the first execution event related to any request is detected, the system interacts with the data collection and scheduling platform to determine whether a first link context corresponding to the request exists. If the first link context is obtained from the acquisition and scheduling platform, the link identifier of the request execution link and the node identifier of the parent execution node of the first execution node are obtained from the first link context; If the data acquisition and scheduling platform returns an indication that the first link context does not exist, it creates a unique link identifier for the requested execution link and sets the parent execution node of the first execution node to null.

3. The method according to claim 2, further comprising: When the detected subsequent execution event is an external call event, a second link context for cross-application propagation is generated based on the link identifier of the request execution link, the node identifier of the execution node corresponding to the external call event, and the description information of the called application. The second link context is pushed to the data acquisition scheduling platform so that the data acquisition scheduling platform distributes the second link context to the data acquisition plugin used to monitor the invoked application.

4. The method according to claim 1, wherein the plurality of execution events includes: Service request handling events, database query events, and external call events; The first execution event associated with any request includes the service request processing event; The subsequent execution events include the database query event and / or the external call event; The completion of the service request processing event indicates that the request has been processed.

5. The method according to claim 4, wherein all execution nodes associated with the request and their corresponding execution information are organized in the structured data in the form of an execution node list; The list items corresponding to each execution node in the execution node list include: the node identifier of the parent execution node, the node identifier of the current node, and execution information; The description information of the monitored application includes at least one of the following: the application identifier of the monitored application, the name of the service provided by the monitored application, and the instance identifier of the service provided by the monitored application; The execution information of any execution node includes at least one of the following: timestamp information, operation description information, execution status information, and classification information; the classification information includes the functional hierarchy type of the execution node. The functional hierarchy types of the execution nodes include network interface request type and database access type. The execution nodes corresponding to the service request processing event and the external call event belong to the network interface request type, and the execution nodes corresponding to the database query event belong to the database access type.

6. A method for processing request execution link data, comprising: Obtain structured data representing the request execution chain in the monitored application, the structured data being generated by the method of any one of claims 1 to 5; Based on pre-stored application metadata and database metadata, the structured data is parsed into multiple data records in a unified data format, with each data record corresponding to an execution node; The data record contains specialized parsing content, which is determined based on the functional level type of the execution node: if the functional level type of the execution node is a network interface request type, the specialized parsing content includes detailed network interface request information obtained from the parsing; if the functional level type of the execution node is a database access type, the specialized parsing content includes detailed database access information obtained from the parsing.

7. The method according to claim 6, further comprising: Data records with a functional level type of network interface request are encapsulated into a first type of message and synchronously sent to the first message queue for risk identification by the network request risk alarm service. In addition, data records with a functional level type of database access are encapsulated into a second type of message and synchronously sent to the second message queue for risk identification by the database risk alarm service. And / or, The data records are encapsulated according to the storage format of the target database to form storage records and persistently stored in the target database for asynchronous use by downstream services. The downstream services run asynchronous query tasks with a timed polling mechanism to periodically query the storage records stored in the target repository within a specified time window and execute corresponding tasks based on the queried storage records.

8. A method for processing request execution link data, comprising: Obtain structured data representing the request execution chain in the monitored application, the structured data being generated by the method of any one of claims 1 to 5; Based on the execution nodes in the structured data, topological nodes are generated, and based on the node identifiers of the parent execution nodes and the node identifiers of the current node carried by the execution nodes, topological edges representing the calling relationships between execution nodes are constructed. A topology graph structure is constructed based on the topology nodes and topology edges, and simultaneously sent to the topology event processing service to generate a lineage graph.

9. An electronic device, characterized in that, include: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1-8 by executing the executable instructions.

10. A computer program product, characterized in that, Includes a computer program / instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1-8.

Images