Complex scene link generation method fusing monomer and micro-service application architecture

Abstract

The invention discloses a complex scene link generation method for fusing a monomer and a micro-service application architecture, and relates to the technical field of intelligent operation and maintenance system data processing, and the method comprises the steps: constructing a micro-service architecture call chain based on log data, and constructing a mixed call chain by fusing a monomer architecture log, and fusing the characteristics of a micro-service architecture and a monomer architecture. The call log information under the two different architectures is organically combined by adding the call ID on the F5ID, which also conforms to the reality that most enterprises have the two architectures at present. According to the method, the defect that a method for constructing a call chain under a single monomer architecture or a single micro-service architecture cannot cover a whole monitoring range is overcome, the monitoring range of the call chain can be expanded, a foundation is laid for subsequent enterprise data analysis, root cause analysis of call chain tracking, fault self-recovery and other requirements, and improvement of enterprise efficiency is facilitated.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing of intelligent operation and maintenance systems, and in particular to a complex scenario link generation method that integrates a monolithic and microservice application architecture. Background Art

[0002] In the field of intelligent operation and maintenance, call chain tracing is the focus and difficulty of research in the field. The so-called call chain tracing refers to monitoring and recording the entire process of each request from initiation to completion in the system, including the interaction between each service node, so as to facilitate tracking the flow path of the request in the system. With the continuous iteration of software system architecture, the architecture of application programs has gradually replaced the monolithic application architecture with the microservice application architecture. Based on the actual situation of business development, there are often scenarios with both monolithic application architecture and microservice application architecture. The patent of this invention proposes a hybrid serial technology that can effectively solve the call chain tracing technology in the hybrid architecture scenario and effectively improve the efficiency of operation and maintenance troubleshooting.

[0003] In the era of monolithic application architecture, there are a series of methods for call relationship tracking:

[0004] 1. Logging: Add logging functionality to your code to record the invocation of each method, including information about the caller and the callee. By analyzing the log information, you can understand the calling relationships of the code.

[0005] 2. Static analysis tools: Use static analysis tools to analyze code dependencies and help identify call relationships. These tools can scan code, identify call relationships between methods, and generate call relationship graphs.

[0006] 3. IDE plug-ins: Some integrated development environments (IDEs) provide plug-ins that can help developers track the call relationships of their code. These plug-ins can generate call relationship graphs to help developers better understand the code.

[0007] 4. Manual debugging: During the development process, you can use manual debugging to track the calling relationships of the code. By setting breakpoints and single-step debugging, you can gradually track the execution flow of the code and understand the calling relationships between methods.

[0008] 5. Documentation and comments: Add detailed comments and documentation to the code to explain the function and calling relationship of each method. This will help developers understand the structure and calling relationship of the code more easily.

[0009] Although these methods are cumbersome and time-consuming, they are still effective ways to track call relationships in the context of a monolithic application architecture, especially the method of building a chain of calls through log data.

[0010] In a microservice application architecture, since the system consists of multiple independent services and there are complex call relationships between services, it is necessary to track and monitor these call relationships in order to promptly discover and resolve problems. The following are some common methods for tracking call relationships in a microservice application architecture:

[0011] 1. Use distributed tracing tools: Distributed tracing tools can help track the transmission and processing of requests between different services, thereby tracing the call relationships of the entire system. Commonly used distributed tracing tools include Zipkin and Jaeger.

[0012] 2. Add a unique identifier: Adding a unique identifier to the request, such as TraceID or Correlation ID, can help track the transmission process of a request between different services, thereby tracing the call relationship.

[0013] 3. Use log aggregation tools: By exporting service logs to log aggregation tools, you can track the call relationships of the entire system. By analyzing and querying the logs, you can understand the transmission and processing process of requests between different services.

[0014] 4. Use a monitoring system: The monitoring system can monitor the operating status and performance indicators of the service. Through the monitoring system, you can understand the call relationship and call count between services, thereby tracking the call relationship.

[0015] 5. Use application performance management tools: Application performance management tools can monitor the performance indicators and operating status of services. Through these indicators, you can understand the call relationship and call performance between services, thereby tracking the call relationship.

[0016] The above method can track and monitor call relationships within a microservice application architecture, helping to identify and resolve issues and improve system reliability and performance. However, real-world applications often involve both monolithic and microservice application architectures, making current technologies impractical for direct enterprise production implementation. Therefore, we propose a method for generating links in complex scenarios that integrates both monolithic and microservice application architectures. Summary of the Invention

[0017] The purpose of the present invention is to solve the problem that under real conditions, most enterprises have two different architectural forms: monolithic architecture and microservice architecture. Therefore, a single architecture cannot completely build a call chain and cannot meet the monitoring needs in real enterprise scenarios. The present invention provides a complex scenario link generation method that integrates monolithic and microservice application architectures.

[0018] In order to achieve the above-mentioned purpose, the present invention specifically adopts the following technical solutions:

[0019] A method for generating links in complex scenarios that integrates monolithic and microservice application architectures, including the following steps:

[0020] Step 1: Build a microservice architecture call chain based on log data. Perform data cleaning on the original logs of the microservice architecture, including deduplication, missing value processing, and abnormal data filtering. Build a recursive tree structure using SpanID and ParentSpanID, generate TraceID as the unique identifier of the call chain, format the input log data, and build a call chain by concatenating the logs. Record the client send time (CS), client receive time (CR), server send time (SS), and server receive time (SR) of the service node, and calculate the performance indicators of each node.

[0021] Step 2: Integrate the monolithic architecture logs to build a hybrid call chain. Split the F5_ID field in the monolithic architecture log to generate a triple of F5_trace_id (first call ID), F5_span_id (current call ID), and F5_parent_span_id (parent call ID). Pattern-match the F5 triple with the microservice call chain, eliminate call ambiguity through the service_endpoint and http_url fields, recursively build the hybrid call chain using a breadth-first or depth-first algorithm, and calculate the performance indicators of each node.

[0022] Furthermore, the performance indicators for each node serving A and B in steps 1 and 2 include the processing time of SS-SR service A, the network time from SR-CS A to B, the network time from CR-SS B to A, the response time of CR-CS service B, and the calculation time of SS-SR-(CR1-CS1)-(CR2-CS2) service A.

[0023] Furthermore, the similarity calculation formula for the cross-architecture call path when the F5 triplet and the microservice call chain are pattern matched in step 2 is:

[0024] Similarity = (number of matching service_endpoint fields + number of matching http_url levels) / (total number of fields + total number of levels)

[0025] If Similarity ≥ 0.8, it is determined to be the same call chain.

[0026] Furthermore, the pattern matching in step 2 is implemented by performing regular expression matching on the F5 triple and the service_endpoint field of the microservice call chain, and combining the http_url path similarity analysis to complete the association of the cross-architecture call chain.

[0027] Furthermore, the formatted fields for data cleaning in step 1 include service type (microservices / single), event type (CR / CS / SS / SR), microservice component type (GATEWAY / SPRING_WEB / FEIGN / HYSTRIX), service endpoint, instance IP, status, and time consumption.

[0028] Furthermore, the splitting method of F5_ID in step 2 is to parse the call sequence by comma separator, the first call ID is used as F5_trace_id, the last call ID is used as F5_span_id, and the previous call ID is used as F5_parent_span_id.

[0029] Furthermore, step 2 also includes a dynamic call chain update mechanism, which monitors the incremental log streams of microservices and monolithic architectures in real time, updates the constructed call chain through timestamp alignment technology, and when a service node status change is detected, uses an incremental topological sorting algorithm to recalculate the call path and marks the failed node as gray and unavailable.

[0030] Furthermore, a security detection module is embedded in the performance indicator calculation process of steps 1 and 2 to perform a security audit on parameter passing in the cross-architecture call chain, and match SQL injection and XSS attack features based on regular expressions. If an abnormal call pattern is detected, a security alarm event is automatically generated, and the risk path is highlighted in the call chain topology diagram.

[0031] Furthermore, steps 1 and 2 support cross-data center call chain association, generate a globally unique identifier (G-TraceID) for the cross-data center call chain, associate the local TraceID through the IP mapping table in the border gateway log, add a transmission time mark to the network transmission node, and distinguish between the service internal processing time and the cross-data center communication time.

[0032] Furthermore, in steps 1 and 2, repetitive call patterns are clustered to generate a call chain template (TemplateID). Only the template ID and difference parameters are retained during storage, and the complete call chain topology is restored through the template library during playback.

[0033] The beneficial effects of the present invention are as follows:

[0034] 1. The present invention integrates the characteristics of microservice architecture and monolithic architecture. By appending the call ID to F5_ID, the call log information under the two different architectures is organically combined. This is also in line with the reality that most enterprises currently have both of the above architectures. This invention overcomes the shortcomings of the method of building a call chain under a single monolithic architecture or a single microservice architecture that cannot cover the entire monitoring range. It can expand the monitoring range of the call chain, lay the foundation for subsequent enterprise data analysis, call chain tracking for root cause analysis, fault self-healing, and other needs, and is more conducive to improving enterprise efficiency.

[0035] 2. By accurately extracting and processing these formatted fields, the present invention can effectively distinguish the log data of monolithic applications and microservice components, obtaining high-quality data for constructing call chains. This data is further refined to specific microservice component types, such as gateways (GATEWAY), Spring Web services (SPRING_WEB), Feign clients (FEIGN), and Hystrix circuit breakers (HYSTRIX), thereby achieving precise control over link generation in complex application scenarios. Identifying service endpoints and instance IP addresses helps quickly locate the specific location of the problem. The status field reflects the success or failure of the request processing, and the time-consuming field is directly related to the key indicators of system performance evaluation.

[0036] 3. In the recursive function of the present invention, for each node, it is first split according to its F5_ID to obtain F5_trace_id, F5_span_id and F5_parent_span_id. These IDs play a key role in the recursive process, not only helping to determine the position of the node in the call chain, but also used to establish the parent-child relationship between nodes. As the unique identifier of the entire call chain, F5_trace_id runs through the entire request process and can track and associate all related calls. F5_span_id identifies the current call, while F5_parent_span_id points to the parent node that calls it. In this way, a clear and orderly call chain can be constructed, providing strong support for subsequent performance analysis and troubleshooting. In the recursive process, each time a node is processed, the call chain will be updated according to its F5_ID information, and the performance indicators of the current node will be calculated and stored for subsequent analysis and use. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below.

[0038] The present invention provides a complex scenario link generation method that integrates a monolithic and microservice application architecture, comprising the following steps:

[0039] Step 1: Build a microservice architecture call chain based on log data. Perform data cleaning on the original logs of the microservice architecture, including deduplication, missing value processing, and abnormal data filtering. Build a recursive tree structure using SpanID and ParentSpanID, generate TraceID as the unique identifier of the call chain, format the input log data, and build a call chain by concatenating the logs to record the client send time (CS), client receive time (CR), server send time (SS), and server receive time (SR) of the service node, and calculate the performance indicators of each node.

[0040] The call chain process of building a microservice architecture based on log data is to first find the head node. In the original log data under the microservice architecture, the head node is generally the one with an empty parent_span_id. Then, the child node is found from the head node. Generally, parent_span_id = span_id is used for recursive search. Then, it is constructed in the form of SR, CS1, CR1, CS2, CS2...SS. The performance indicators of each node are calculated through breadth-first (or depth-first) recursion.

[0041] Breadth-first and depth-first recursive methods are used to build the call chain process of the microservice architecture. The following are the implementation ideas of these two methods:

[0042] Breadth-first recursive method:

[0043] 1 Initialize a queue and add the head node to the queue.

[0044] 2. When the queue is not empty, perform the following steps:

[0045] 2.1 Take a node from the queue and use it as the current node.

[0046] 2.2 Based on the span_id of the current node, find all child nodes whose parent_span_id is equal to the span_id of the current node in the log data.

[0047] 2.3 Add the found child nodes to the queue in the order of SR, CS1, CR1, CS2, ..., SS.

[0048] 2.4 Calculate the performance indicators of the current node.

[0049] 3 Repeat step 2 until the queue is empty.

[0050] Depth-first recursive approach:

[0051] 1 Define a recursive function with the current node as input parameter.

[0052] 2In the recursive function, perform the following steps:

[0053] 2.1 Based on the span_id of the current node, find all child nodes whose parent_span_id is equal to the span_id of the current node in the log data.

[0054] 2.2 Recursively call the recursive function for each child node in the order of SR, CS1, CR1, CS2, ..., SS.

[0055] 2.3 Calculate the performance indicators of the current node.

[0056] 3. Call the recursive function with the head node as input parameter.

[0057] When building a call chain, it's important to ensure the integrity and accuracy of log data, as well as the uniqueness and correctness of the call chain. Furthermore, for complex call relationships within a microservice architecture, a combination of breadth-first and depth-first methods, or other graph algorithms, may be necessary.

[0058] The formatted fields for data cleaning include service type (microservices / single), event type (CR / CS / SS / SR), microservice component type (GATEWAY / SPRING_WEB / FEIGN / HYSTRIX), service endpoint, instance IP, status, and duration.

[0059] By accurately extracting and processing these formatted fields, the present invention can effectively distinguish the log data of monolithic applications and microservice components, obtaining high-quality data for constructing call chains. This data can be further refined to specific microservice component types, such as gateways (GATEWAY), Spring Web services (SPRING_WEB), Feign clients (FEIGN), and Hystrix circuit breakers (HYSTRIX), thereby achieving precise control over link generation in complex application scenarios. Identifying service endpoints and instance IP addresses helps quickly locate the specific location of the problem. The status field reflects the success or failure of the request processing, and the time-consuming field is directly related to the key indicators of system performance evaluation.

[0060] Step 2: Integrate the monolithic architecture logs to build a hybrid call chain. Split the F5_ID field in the monolithic architecture log to generate a triple of F5_trace_id (first call ID), F5_span_id (current call ID), and F5_parent_span_id (parent call ID). Pattern-match the F5 triple with the microservice call chain, eliminate call ambiguity through the service_endpoint and http_url fields, recursively build the hybrid call chain using a breadth-first or depth-first algorithm, and calculate the performance indicators of each node.

[0061] The process for building a hybrid call chain by integrating logs from a monolithic architecture is to first find the head node, typically the one with an empty parent_span_id. From the head node, child nodes are then found, typically recursively using the formula parent_span_id = span_id. The chain is then constructed using the SR, CS1, CR1, CS2, CS2, and finally SS order, using a breadth-first (or depth-first) approach. If no child node is found, concatenation is attempted using F5_span. However, F5 concatenation is ambiguous (i.e., two requests may be packaged through F5), so pattern matching is performed using service_endpoint and http_url to calculate performance metrics for each node.

[0062] The F5_ID is split by parsing the call sequence by comma separators, with the first call ID as F5_trace_id, the last call ID as F5_span_id, and the previous call ID as F5_parent_span_id.

[0063] In the recursive function, each node is first split based on its F5_ID to obtain the F5_trace_id, F5_span_id, and F5_parent_span_id. These IDs play a key role in the recursive process, not only helping to determine the node's position in the call chain but also establishing parent-child relationships between nodes. The F5_trace_id uniquely identifies the entire call chain and is used throughout the entire request process to track and correlate all related calls.

[0064] The F5_span_id identifies the current call, while the F5_parent_span_id points to the parent node that called it. This allows for the construction of a clear, organized call chain, providing powerful support for subsequent performance analysis and troubleshooting. During the recursive process, each time a node is processed, the call chain is updated based on its F5_ID information, and the performance metrics of the current node are calculated and stored for subsequent analysis and use.

[0065] The formula for calculating the similarity of cross-architecture call paths when performing pattern matching between F5 triples and microservice call chains is:

[0066] Similarity = (number of matching service_endpoint fields + number of matching http_url levels) / (total number of fields + total number of levels)

[0067] If Similarity ≥ 0.8, it is determined to be the same call chain.

[0068] When performing pattern matching, this similarity calculation formula accurately measures the similarity between F5 triples and microservice call chains. Matching the service_endpoint field reflects the relevance of the service endpoints, while matching the number of http_url levels reflects the consistency of the request path. By calculating the ratio of the number of matching fields and levels to the total number of fields and levels, we obtain a similarity value between 0 and 1. When the similarity is greater than or equal to 0.8, we have reason to believe that the two call chains are related, meaning they belong to the same call chain. This determination method not only improves the accuracy of call chain identification but also provides a strong basis for subsequent performance monitoring and troubleshooting.

[0069] Pattern matching is implemented by performing regular expression matching on the F5 triples and the service_endpoint field in the microservice call chain, combined with http_url path similarity analysis to associate cross-architecture call chains and achieve seamless connectivity across these chains. During the regular expression matching process, the powerful pattern matching capabilities of regular expressions are leveraged to accurately match the F5 triples and the service_endpoint field in the microservice call chain. Simultaneously, combined with http_url path similarity analysis, the call chain association logic is further refined, ensuring the accuracy and completeness of cross-architecture call chains. This approach effectively integrates log data from both monolithic and microservice architectures to construct a comprehensive and accurate view of call chains, providing powerful support for system performance monitoring, troubleshooting, and optimization.

[0070] The dynamic call chain update mechanism monitors incremental log streams from microservices and monolithic architectures in real time and updates the constructed call chain using timestamp alignment technology. When a service node status change is detected, an incremental topological sorting algorithm is used to recalculate the call path and mark the failed node as gray and unavailable. This ensures the real-time and accuracy of the call chain view. Even if service nodes are added, removed, or their status changes occur during system operation, they are quickly reflected in the call chain view. Timestamp alignment effectively prevents call chain breakage caused by log time discrepancies, maintaining the continuity of the call chain. The application of the incremental topological sorting algorithm greatly improves the efficiency of call path recalculation and reduces system resource consumption. By marking failed nodes as gray and unavailable, operations and maintenance personnel can easily identify problematic nodes in the current system, allowing them to quickly locate the fault and implement appropriate remediation measures. This dynamic call chain update mechanism provides strong support for link generation in complex scenarios, significantly improving system maintainability and stability.

[0071] The performance indicators of each node of services A and B include the processing time of SS-SR service A, the network time from SR-CS A to B, the network time from CR-SS B to A, the response time of CR-CS service B, and the calculation time of SS-SR-(CR1-CS1)-(CR2-CS2) service A.

[0072] These performance metrics provide operations and maintenance personnel with rich information about the system's operational status. The SS-SR processing time for service A reflects the time it takes service A to process a request and is a key indicator for evaluating service A's performance. The SR-CS network time from A to B reveals the network transmission delay from service A to service B, helping to analyze network bottlenecks. The CR-SS network time from B to A reflects the time it takes for service B to return data to service A, which is crucial for evaluating bidirectional network transmission performance. The CR-CS response time for service B shows the time it takes service B to process a request and return the result, making it a key indicator for evaluating service B's response speed. The SS-SR-(CR1-CS1)-(CR2-CS2) calculation time for service A comprehensively considers multiple steps in service A's request processing, including request sending, receiving, processing, and response, providing a basis for in-depth analysis of service A's overall performance.

[0073] If the service node is called asynchronously, the time taken is corrected according to the following formula:

[0074] T_process_async=max(SS_list)-min(SR_list)

[0075] SS_list and SR_list are multiple SS / SR timestamp sets under the same SpanID.

[0076] The detailed calculation of network transmission time (T_network) includes:

[0077] Transmission time from client to server: T_client2server = SS - CS

[0078] Transmission time from server to client: T_server2client = CR - SR

[0079] Mark the bidirectional transmission time in the network topology diagram and mark abnormal fluctuations.

[0080] A security detection module is embedded in the performance indicator calculation process to conduct security audits on parameter passing in cross-architecture call chains. It matches SQL injection and XSS attack features based on regular expressions. If an abnormal call pattern is detected, a security alarm event is automatically generated and the risk path is highlighted in the call chain topology diagram. It has real-time monitoring and early warning functions, can promptly discover and respond to potential security threats, effectively prevent the occurrence of security vulnerabilities such as SQL injection and XSS attacks, and ensure the safe and stable operation of the system.

[0081] The method of the present invention supports cross-data center call chain association, generates a globally unique identifier (G-TraceID) for the cross-data center call chain, associates the local TraceID through the IP mapping table in the border gateway log, adds a transmission time mark at the network transmission node, distinguishes the service internal processing time from the cross-data center communication time, and realizes accurate tracking and performance analysis of the cross-data center call chain. Through the introduction of the globally unique identifier (G-TraceID), the call chains distributed in different data centers can be associated to form a complete call chain view. The IP mapping table in the border gateway log plays the role of a bridge, which can associate the local TraceID so that the call chain across data centers can be seamlessly connected. Adding the transmission time mark at the network transmission node allows us to clearly distinguish the service internal processing time from the cross-data center communication time, providing more accurate data support for performance analysis and optimization. In this way, operation and maintenance personnel can more accurately locate performance bottlenecks, take corresponding optimization measures, and improve the overall performance of the system.

[0082] In the method of the present invention, repetitive call patterns are clustered to generate a call chain template (TemplateID). Only the template ID and difference parameters are retained during storage, and the complete call chain topology is restored through the template library during playback. Through pattern clustering technology, repetitive call patterns with similar call characteristics can be identified and summarized, and these patterns are further abstracted into call chain templates. Each template is assigned a unique TemplateID for easy management and reference. When storing call chain information, the system no longer saves the complete call chain details, but only records the template ID and those difference parameters that do not completely match the template. This approach greatly saves storage space and improves data processing efficiency. When the call chain needs to be replayed or analyzed, the system can quickly restore the complete call chain topology by searching the template library and combining the difference parameters. This method improves the efficiency of historical data queries and not only simplifies the management and analysis process of the call chain, but also improves the flexibility and scalability of the system.

[0083] The present invention integrates the characteristics of microservice architecture and monolithic architecture. By appending the call ID to F5_ID, the call log information under the two different architectures is organically combined. This is also in line with the reality that most enterprises currently have both of the above architectures. This invention overcomes the shortcomings of the method of building a call chain under a single monolithic architecture or a single microservice architecture that cannot cover the entire monitoring range. It can expand the monitoring range of the call chain, lay the foundation for subsequent enterprise data analysis, call chain tracking for root cause analysis, fault self-healing, and other needs, and is more conducive to improving enterprise efficiency.

[0084] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A complex scenario link generation method that integrates a monolithic and microservice application architecture, characterized by: The following steps are involved: Step 1: Build a microservice architecture call chain based on log data. Perform data cleaning on the original logs of the microservice architecture, including deduplication, missing value processing, and abnormal data filtering. Build a recursive tree structure using SpanID and ParentSpanID, generate TraceID as the unique identifier of the call chain, format the input log data, and build a call chain by concatenating the logs. Record the client send time (CS), client receive time (CR), server send time (SS), and server receive time (SR) of the service node, and calculate the performance indicators of each node. Step 2: Integrate the monolithic architecture logs to build a hybrid call chain. Split the F5_ID field in the monolithic architecture log to generate a triple of F5_trace_id (first call ID), F5_span_id (current call ID), and F5_parent_span_id (parent call ID). Pattern-match the F5 triple with the microservice call chain, eliminate call ambiguity through the service_endpoint and http_url fields, recursively build the hybrid call chain using a breadth-first or depth-first algorithm, and calculate the performance indicators of each node.

2. The complex scenario link generation method for integrating a monolithic and microservice application architecture according to claim 1 is characterized by: The performance indicators for each node serving A and B in steps 1 and 2 include the processing time of SS-SR service A, the network time from SR-CS A to B, the network time from CR-SS B to A, the response time of CR-CS service B, and the calculation time of SS-SR-(CR1-CS1)-(CR2-CS2) service A.

3. The complex scenario link generation method for integrating a monolithic and microservice application architecture according to claim 1 is characterized by: The similarity calculation formula for the cross-architecture call path when the F5 triplet and the microservice call chain are pattern matched in step 2 is: Similarity = (number of matching service_endpoint fields + number of matching http_url levels) / (total number of fields + total number of levels) If Similarity ≥ 0.8, it is determined to be the same call chain.

4. The complex scenario link generation method for integrating a monolithic and microservice application architecture according to claim 3 is characterized by: The pattern matching in step 2 is implemented by performing regular expression matching on the F5 triple and the service_endpoint field of the microservice call chain, and combining the http_url path similarity analysis to complete the association of the cross-architecture call chain.

5. The complex scenario link generation method for integrating a monolithic and microservice application architecture according to claim 1 is characterized by: The formatting fields of the data cleansing in step 1 include the service type (microservices / single), event type (CR / CS / SS / SR), microservice component type (GATEWAY / SPRING_WEB / FEIGN / HYSTRIX), service endpoint, instance IP, status, and duration.

6. The complex scenario link generation method for integrating a monolithic and microservice application architecture according to claim 1 is characterized by: The splitting method of F5_ID in step 2 is to parse the call sequence by comma separator, the first call ID is used as F5_trace_id, the last call ID is used as F5_span_id, and the previous call ID is used as F5_parent_span_id.

7. The complex scenario link generation method for integrating a monolithic and microservice application architecture according to claim 1 is characterized by: Step 2 also includes a dynamic call chain update mechanism, which monitors the incremental log streams of microservices and monolithic architectures in real time, updates the constructed call chain through timestamp alignment technology, and when a service node status change is detected, recalculates the call path using an incremental topological sorting algorithm and marks the failed node as gray and unavailable.

8. The complex scenario link generation method for integrating a monolithic and microservice application architecture according to claim 1 is characterized by: The security detection module is embedded in the performance indicator calculation process of step 1 and step 2 to perform security audit on parameter transfer in cross-architecture call chain, and match SQL injection, XSS based on regular expressions. Attack signature: If an abnormal call pattern is detected, a security alert event will be automatically generated and the risk path will be highlighted in the call chain topology diagram.

9. The complex scenario link generation method for integrating a monolithic and microservice application architecture according to claim 1 is characterized by: Steps 1 and 2 support cross-data center call chain association, generate a globally unique identifier (G-TraceID) for the cross-data center call chain, associate the local TraceID through the IP mapping table in the border gateway log, add a transmission time mark to the network transmission node, and distinguish between the service internal processing time and the cross-data center communication time.

10. The complex scenario link generation method integrating a monolithic and microservice application architecture according to claim 1 is characterized by: In steps 1 and 2, repetitive call patterns are clustered to generate a call chain template (TemplateID). Only the template ID and difference parameters are retained during storage, and the complete call chain topology is restored through the template library during playback.