A service link tracking method, system, medium and electronic device

Abstract

The application provides a service link tracking method and system, a medium and an electronic device, and relates to the technical field of data processing. In response to receiving a service call request from a first protocol environment, link tracking context information of a first protocol carried in the service call request is identified. The link tracking context information of the first protocol in the service call request is converted into link tracking context information conforming to a second protocol to obtain a target request. The target request is sent to a target service in the second protocol environment, so that the target service performs a business operation corresponding to the target request. During the execution of the business operation by the target service, when at least one preset type of business call operation is detected, semantic data associated with the business call operation is collected based on the link tracking context information of the second protocol to form enhanced link tracking information containing the semantic data. Cross-protocol service link tracking can be achieved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a service link tracing method, system, medium, and electronic device. Background Technology

[0002] In a microservices architecture, applications are typically composed of service components developed in multiple programming languages. Distributed distributed tracing technology is widely used to monitor calls between these distributed services. This technology reconstructs the complete call chain by embedding tracking points in each service along the path of a request and reporting data with specific identifiers. Currently, various distributed tracing systems exist, such as Zipkin and SkyWalking, each with its own custom context propagation protocol.

[0003] However, when services implemented in different languages ​​are deployed in a mixed manner, the tracing protocols used by each service are often different. For example, a Java service might use SkyWalking's SW8 protocol, while a PHP service might use Zipkin's B3 protocol. Due to the incompatibility of these protocols, when a call from one service enters another service, its service context cannot be correctly identified and inherited, causing the service chain to break at the cross-language point and making it impossible to form an effective service chain tracing. Summary of the Invention

[0004] The technical problem this application aims to solve is to provide a service link tracing method, system, medium, and electronic device, demonstrating how to achieve service link tracing across tracing protocols. The specific solution is as follows:

[0005] A service tracing method, comprising:

[0006] In response to receiving a service call request from a first protocol environment, the link tracing context information of the first protocol carried in the service call request is identified;

[0007] The link tracing context information of the first protocol in the service call request is converted into link tracing context information conforming to the second protocol to obtain the target request;

[0008] The target request is sent to the target service in the second protocol environment so that the target service performs the business operation corresponding to the target request;

[0009] During the execution of business operations by the target service, when at least one preset type of business call operation is detected, semantic data associated with the business call operation is collected based on the link tracing context information of the second protocol to form enhanced link tracing information containing the semantic data.

[0010] Optionally, in the above method, converting the link tracing context information of the first protocol into link tracing context information conforming to the second protocol includes:

[0011] Extract the global tracking identifier and the current span identifier from the link tracing context information of the first protocol;

[0012] Map the global tracking identifier to a tracking identifier in the second protocol format, and map the current span identifier to a parent span identifier in the second protocol format;

[0013] According to the specification structure of the second protocol, the mapped tracking identifier, parent span identifier, and preset service metadata are assembled to generate the second protocol link tracing context information.

[0014] Optionally, in the above method, the preset type of business call operation includes an HTTP call; the collection of semantic data associated with the business call operation includes:

[0015] When an HTTP call is detected in the business operation, the link tracing context information of the second protocol is converted into a format suitable for HTTP propagation and injected into the request header of the HTTP call;

[0016] Capture the target address and request method of the HTTP call;

[0017] The target address and request method are collected as semantic data.

[0018] Optionally, in the above method, the preset type of business call operation includes a database query operation; the collection of semantic data associated with the business call operation includes:

[0019] When a database query is detected during the business operation, the original query statement to be executed is obtained;

[0020] The original query statement is parameterized to generate a templated query statement;

[0021] The templated query statement and its corresponding database identifier are collected as semantic data.

[0022] Optionally, the above method may further include:

[0023] Record the execution time of the database query operation;

[0024] The execution time is collected as semantic data.

[0025] Optionally, when the service call request is a command-line task, the method further includes:

[0026] At the command-line task execution entry point, create a root span based on the second protocol link tracing context information;

[0027] Get the script identifier and input parameters of the current command-line task;

[0028] The script identifier and the input parameters are recorded as attribute data for the root span.

[0029] A service link tracing device, comprising:

[0030] The identification unit is configured to, in response to receiving a service call request from a first protocol environment, identify the link tracing context information of the first protocol carried in the service call request;

[0031] The conversion unit is used to convert the link tracing context information of the first protocol in the service call request into link tracing context information conforming to the second protocol to obtain the target request;

[0032] The first execution unit is used to send the target request to the target service in the second protocol environment, so that the target service performs the business operation corresponding to the target request;

[0033] The second execution unit is used to collect semantic data associated with the business call operation based on the link tracing context information of the second protocol when at least one preset type of business call operation is detected during the execution of business operations by the target service, so as to form enhanced link tracing information containing the semantic data.

[0034] Optionally, the conversion unit in the aforementioned apparatus includes:

[0035] The extraction subunit is used to extract the global tracking identifier and the current span identifier from the link tracing context information of the first protocol;

[0036] The mapping subunit is used to map the global tracking identifier to a tracking identifier in the second protocol format, and to map the current span identifier to a parent span identifier in the second protocol format;

[0037] The generation sub-unit is used to assemble the mapped tracking identifier, parent span identifier, and preset service metadata according to the specification structure of the second protocol to generate the second protocol link tracing context information.

[0038] A storage medium includes storage instructions, wherein, when the instructions are executed, the device in which the storage medium resides executes the service link tracing method as described above.

[0039] An electronic device includes a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors using the service link tracing method described above.

[0040] Based on the above, this application provides a service tracing method, system, medium, and electronic device, comprising: responding to receiving a service call request from a first protocol environment, identifying tracing context information of the first protocol carried in the service call request; converting the tracing context information of the first protocol in the service call request into tracing context information conforming to a second protocol to obtain a target request; sending the target request to a target service in the second protocol environment, so that the target service performs a business operation corresponding to the target request; during the execution of the business operation by the target service, when at least one preset type of business call operation is detected, collecting semantic data associated with the business call operation based on the tracing context information of the second protocol to form enhanced tracing information containing the semantic data. This enables service tracing across tracing protocols. Attached Figure Description

[0041] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0042] Figure 1 A flowchart of a service link tracing method provided in this application;

[0043] Figure 2 A flowchart illustrating the process of converting link tracing context information of a first protocol into link tracing context information conforming to a second protocol, provided in this application;

[0044] Figure 3 A flowchart of a cross-language service link tracing process is provided for this application;

[0045] Figure 4 This application provides a schematic diagram of the structure of a service link tracing system;

[0046] Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

[0047] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0048] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, 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, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0049] This application provides a service link tracing method, which can be applied to electronic devices, such as personal computers, server computers, or various types of smart terminals. The method flowchart is shown below. Figure 1 As shown, it specifically includes:

[0050] S101: In response to receiving a service call request from the first protocol environment, identify the link tracing context information of the first protocol carried in the service call request.

[0051] In this embodiment, the first protocol environment refers to the runtime environment employing a first type of linked tracing protocol. For example, the first type of linked tracing protocol could be the Zipkin protocol, which can propagate the linked tracing context through specific HTTP header fields, such as X-B3-TraceId or X-B3-SpanId. The service call request can refer to a remote procedure call request based on protocols such as HTTP or gRPC.

[0052] Optionally, the tracing context information is a set of metadata used to uniquely identify and associate a complete request chain in a distributed system. In the first protocol, this context information includes at least a globally unique trace identifier (TraceID) and a span identifier (Span ID) used to identify the current call position. The identification process is mainly accomplished by parsing predefined fields in the header of the service call request. In addition, this context information may also include other control or descriptive information such as sampling decisions and parent span identifiers.

[0053] S102: Convert the link tracing context information of the first protocol in the service call request into link tracing context information conforming to the second protocol to obtain the target request.

[0054] For example, the second type of link tracing protocol can be a different protocol from the first type of link tracing protocol, such as the SkyWalking protocol.

[0055] In some embodiments, the first type of link tracing protocol may be the SkyWalking protocol, and the second type of link tracing protocol may be the Zipkin protocol.

[0056] Optionally, identifiers, such as the global tracking identifier and the current span identifier, can be extracted from the first protocol context information. Subsequently, these identifiers are re-encapsulated according to the data format and encoding method specified by the second protocol (e.g., Base64-encoded string concatenation rules), and other metadata fields required by the second protocol are supplemented, such as service name, service instance identifier, endpoint information, etc. In implementation, this transformation operation can be completed by a separate protocol adapter component deployed on the ingress traffic path of the service request. Through transformation, a new request, the target request, is generated that conforms to the second protocol specification in content but retains the same business load.

[0057] S103: Send the target request to the target service in the second protocol environment so that the target service can perform the business operation corresponding to the target request.

[0058] As is easily understood, the target service can be a backend service that provides business logic processing capabilities, running in an environment that integrates a second-protocol link tracing proxy or SDK. Sending the target request to the target service completes the transfer of cross-protocol link context.

[0059] Optionally, upon receiving the request, the target service's built-in tracing component, Agent, can identify the tracing context information conforming to the second protocol from the request header and use this as the parent context for this business call in the distributed tracing chain. Based on this, the target service begins to execute the specific business logic carried by the request, such as order processing, data querying, or computational tasks.

[0060] S104: During the execution of business operations by the target service, when at least one preset type of business call operation is detected, semantic data associated with the business call operation is collected based on the link tracing context information of the second protocol to form enhanced link tracing information containing semantic data.

[0061] Among these, the pre-defined business call operations refer to cross-boundary operations within the service. Examples include HTTP calls to external services, database queries, and command-line task execution. This can be achieved by enhancing the functionality of relevant components at the application framework level of the target service, such as by embedding interception logic in the HTTP client library, database driver, or task execution entry point. When the business logic reaches these pre-defined operation points, the enhanced components will be triggered.

[0062] Optionally, the tracing context (including TraceID, Span ID, etc.) already established in the target service request can be used as an anchor point for collecting semantic data. Semantic data describes the details of the specific operation. For HTTP calls, semantic data may include the target URL, HTTP method, and request header summary; for database operations, it may include the parameterized SQL template, database name, and execution time; for command-line tasks, it may include the script name, input parameters, etc. This collected semantic data will be appended to the current tracing context and recorded as Span tags or logs.

[0063] In this embodiment, the target service and its enhanced components asynchronously report all link tracing information generated by this business operation, including basic context and collected semantic data, to the link tracing backend system. Thus, the enhanced link tracing information, while preserving the continuity of cross-protocol call links, further enriches the observable details within the service on the second protocol environment side, achieving an improvement in the depth and consistency of end-to-end link tracing.

[0064] In one embodiment provided in this application, based on the above-described scheme, optionally, the process of converting the link tracing context information of the first protocol into link tracing context information conforming to the second protocol is as follows: Figure 2 As shown, it includes:

[0065] S201: Extract the global tracing identifier and the current span identifier from the link tracing context information of the first protocol.

[0066] The global trace identifier is a string used to uniquely identify a complete business request chain in a distributed system. In the first protocol, this identifier can be carried in a specific HTTP request header field, such as the header field named X-B3-TraceId. Its format can be a string of hexadecimal numbers or an encoded string to ensure global uniqueness in a complex call chain network. The current span identifier is an identifier used to identify the position of the current service call node in the overall chain. It also originates from a specific header field in the first protocol, such as the field named X-B3-SpanId. This identifier can be used in conjunction with the global trace identifier to represent parent-child or sequential call relationships. The extraction operation involves locating and reading the string values ​​corresponding to the above predefined fields by parsing the header of the service call request.

[0067] S202: Map the global tracking identifier to a tracking identifier in the second protocol format, and map the current span identifier to the parent span identifier in the second protocol format.

[0068] In this embodiment, the mapping operation refers to converting the identifier value in the source protocol into an identifier that conforms to the format requirements or field naming conventions of the target protocol. Since different link tracing protocols may have different encoding rules, field names, and semantics for identifiers, mapping is necessary.

[0069] For example, the global trace identifier of the first protocol might be a hexadecimal string, while the second protocol might require the trace identifier to be Base64 encoded. Therefore, the mapping process might involve an encoding conversion. However, in another alternative implementation, if the two protocols require the same character set for the identifier, the mapping could be a direct reuse of the identifier value. Similarly, mapping the current span identifier of the first protocol to the parent span identifier of the second protocol involves a conceptual transformation. In the first protocol, this identifier represents the current calling node, but when it is injected into a request sent downstream (the second protocol environment), for the downstream service, this identifier represents the span position of the upstream caller (parent node). Therefore, it needs to be placed in a field representing the parent span position in the second protocol specification, such as the field corresponding to the parent span ID in the SW8 protocol.

[0070] S203: According to the specification structure of the second protocol, the mapped tracking identifier, parent span identifier and preset service metadata are assembled to generate the second protocol link tracing context information.

[0071] Optionally, the canonical structure of the second protocol refers to the complete data format explicitly defined by the protocol for carrying link information in requests. This format is a specific string composed of multiple ordered fields, or a set of HTTP headers with fixed naming rules.

[0072] In this embodiment, the preset service metadata is additional information about the state of the service that is currently making the request, which can be obtained from the service instance configuration or runtime environment where the conversion operation is executed. For example, the service metadata may include the name of the current service, the host address or identifier of the current service instance, and the name of the entry endpoint for this call, etc.

[0073] The assembly process involves combining the mapped tracing identifier, the mapped parent span identifier, and the aforementioned service metadata obtained locally, according to the field order, delimiters, and encoding methods specified in the second protocol specification, into a complete, compliant string or header field value. For example, in the SW8 protocol, this might require Base64 encoding all field values ​​before concatenating them with specific characters. The resulting information is a link tracing context that can be directly recognized and parsed by the tracing agent or middleware in the second protocol environment, completing the conversion from the first protocol format to the second protocol format.

[0074] In one embodiment provided in this application, based on the above-described scheme, optionally, the preset type of business invocation operation includes an HTTP invocation; collecting semantic data associated with the business invocation operation includes:

[0075] When an HTTP call is detected during a business operation, the link tracing context information of the second protocol is converted into a format suitable for HTTP propagation and injected into the request header of the HTTP call.

[0076] Capture the target address and request method of the HTTP call;

[0077] The target address and request method are collected as semantic data.

[0078] In this embodiment, an HTTP call refers to a network request initiated by the target service to another external service during business logic processing, based on the Hypertext Transfer Protocol (HTTP) or its secure version (HTTPS). This can be detected by setting an intercept point or enhancement handler on the call path of the target service application's HTTP client library.

[0079] This interception logic is triggered when the business code executes to the function that initiates a network request. The distributed tracing context information of the second protocol may exist internally within the service as objects or specific data structures. These internal data structures can be serialized into one or more strings according to the standard field format defined by the second protocol itself for context passing between HTTP requests. For example, the SW8 protocol defines an HTTP header field named sw8 to carry its complete context information.

[0080] Optionally, the injection operation involves adding the serialized string as a key-value pair to the upcoming HTTP request object, which is then part of the standard HTTP request header. This ensures that new child spans generated by this outbound call can be correctly associated with the parent request currently being processed by the service in the distributed tracing backend system, thus continuing the call chain.

[0081] In this embodiment, the target address refers to the network identifier of the server endpoint that this HTTP call intends to access. Its specific form can be a complete Uniform Resource Locator (URL); or, in some implementations, it may be captured as the host and port portions. The request method refers to the instruction defined by the HTTP protocol that indicates the type of operation on the resource, commonly including GET, POST, PUT, DELETE, etc. This information can be obtained directly from the parameters constructing the HTTP request object or from the attributes of the request object itself. Capturing this metadata is for subsequent reporting as part of semantic data to describe the specific behavior of this external call.

[0082] Optionally, the captured target address and request method can be associated with the current second-protocol tracing context, and the recorded process can be formatted. In implementation, this information can be appended as key-value pairs to the current span as tags or attributes. For example, a tag with the key `http.url` and the value of the captured URL might be generated, along with a tag with the key `http.method` and the value of `GET`. Subsequently, when the span is asynchronously reported to the tracing backend system, the target address and request method are persistently stored as detailed, queryable semantic information about this HTTP call. This allows for a clear view of the specific target and operation type of each cross-service call during subsequent troubleshooting, service dependency analysis, or interface performance statistics, greatly enhancing the readability and usability of the tracing data.

[0083] In one embodiment provided in this application, based on the above-described solution, optionally, the preset type of business invocation operation includes a database query operation; collecting semantic data associated with the business invocation operation includes:

[0084] When a database query is detected during a business operation, the original query statement to be executed is obtained.

[0085] The original query statement is parameterized to generate a templated query statement;

[0086] Templated query statements and their corresponding database identifiers are collected as semantic data.

[0087] When a database query is detected during a business operation, the original query statement to be executed is obtained.

[0088] In this embodiment, during the execution of business logic, the target service initiates data retrieval or operation instructions to the database management system through a database connection driver or object-relational mapping framework to perform database queries.

[0089] Optionally, detection can be achieved by embedding specific interception or event listener functionality at the database access layer of the target service application, such as during the execution preparation phase of the PDO (PHP Data Objects) extension, or during the construction and query execution preparation stage of the ORM framework. This listener is triggered when the business logic calls the database execution function. The raw query statement to be executed refers to the complete Structured Query Language (SQL) command string that will be sent to the database server at the time of the execution call.

[0090] Specifically, parameterization is a data anonymization and normalization process used to protect user privacy and data security, while standardizing specific queries into a general pattern for easier aggregation and analysis. This process identifies literal values ​​in the original query statement, such as numbers and string constants, and replaces them with uniform placeholders, such as question marks or named parameter identifiers.

[0091] Optionally, semantic data collection refers to the process of associating and recording the generated templated query statements and database identifier information with the currently active tracing context. The database identifier indicates the target database for this query; its specific content can be the logical name of the database read from the application configuration or the physical address information parsed from the database connection string. In the collection implementation, the templated query statement can be recorded as a key-value pair label. Simultaneously, the database identifier is recorded as another label. These label data are appended to the tracing span representing the current database query operation. Finally, this span, along with all its semantic labels, is asynchronously reported to the tracing backend.

[0092] In one embodiment provided in this application, based on the above-described solution, the method may optionally further include:

[0093] Record the execution time of database query operations;

[0094] Execution time is collected as semantic data.

[0095] Execution time is a performance metric used to measure the total time consumed from initiating a database query operation to receiving a response from the database server. The recording of this operation can be implemented using a timing mechanism established when a database query operation is detected. For example, this mechanism can obtain a high-precision timestamp as the start time T1 before the interception logic is triggered and the query is prepared to execute. Subsequently, at the callback point where the database driver returns the execution result or at a subsequent interception point, another high-precision timestamp is obtained as the end time T2. The execution time is calculated as the difference between time point T2 and time point T1 (Δt = T2 - T1).

[0096] Collecting execution time as semantic data involves associating the calculated execution time with the corresponding tracing span of the current database query and reporting it. Specifically, this execution time can be used as an independent performance metric or a specific label attached to the current span. Collecting and reporting execution time as semantic data to the tracing backend system provides quantitative foundational data for system performance analysis, bottleneck diagnosis, and capacity planning. By correlating and analyzing specific query templates with their execution times, operations and development personnel can effectively identify slow queries, pinpoint database performance bottlenecks, and implement targeted optimizations. This allows tracing information to not only possess call topology and contextual semantics but also integrate key performance observation dimensions, achieving deep fusion of observable data.

[0097] In one embodiment provided in this application, based on the above solution, optionally, when the service call request is a command-line task, the method further includes:

[0098] At the command-line task execution entry point, create a root span based on the second protocol link tracing context information;

[0099] Get the script identifier and input parameters of the current command-line task;

[0100] Record the script identifier and the input parameters as attribute data for the root span.

[0101] In this embodiment, a command-line task refers to a background process or batch script that can be started and executed by the operating system command line, rather than being triggered through a regular HTTP or RPC service interface. For such tasks, the entry point can be the beginning of the main program of a separate script file. Creating a root span establishes an initial tracing node in the distributed tracing system, serving as the starting point of the entire call chain. The newly created root span will conform to and integrate the specifications and data format of the second protocol. In practice, this can be achieved by explicitly initializing the second protocol's tracer and calling its application programming interface (API) for creating the root span within the code of the entry script. This root span will generate a new global tracing identifier that conforms to the second protocol specification, and its own span identifier will be set to the initial value.

[0102] Optionally, the script identifier refers to the name or path information used to uniquely identify the executed command-line program itself. In scripting language environments such as PHP, this identifier can be obtained through predefined server-wide variables, and its content is represented as the relative or absolute path of the script file. Input parameters refer to the list of space-separated parameter strings entered through the command-line interface immediately following the script name when starting the command-line task.

[0103] In this embodiment, the obtained script identifier string and input parameter string are appended to the previously created root span object in the form of key-value pairs.

[0104] To clearly illustrate a specific implementation process of the solution in this application, an example scenario is provided below. See [link / reference] Figure 3 The flowchart provided in this application embodiment illustrates a cross-language service link tracing process, specifically including the following:

[0105] In one optional embodiment, to achieve interoperability between heterogeneous link tracing protocols, this application constructs a bidirectional link protocol adaptation and conversion mechanism. The core of this mechanism lies in the adapters deployed on the entry side of different protocol environments, which are responsible for identifying, converting, and re-injecting the link tracing context of inbound requests.

[0106] First, a B3 to SW8 protocol adapter, deployed at the entry point of the first protocol environment (such as a Java service cluster), handles inbound requests originating from the second protocol environment (such as a PHP service). This adapter can be deployed as a standalone sidecar proxy or integrated into an API gateway. Its workflow includes:

[0107] Step S11, Identification and Parsing: The adapter listens for HTTP requests. When it detects that the request header contains the Zipkin standard B3 propagation field (e.g., at least X-B3-TraceId and X-B3-SpanId), it determines that the request carries a Zipkin link context.

[0108] Step S12, Extraction and Mapping: The adapter precisely extracts the globally unique trace identifier (TraceId) and the span identifier (SpanId) representing the current call location from the B3 field above. Optionally, other relevant information such as sampling flags can also be extracted.

[0109] Step S13, Conversion and Encapsulation: The adapter will encode and reassemble the extracted core identifiers in strict accordance with SkyWalking's SW8 protocol specifications.

[0110] Optionally, the SW8 protocol header string consists of 8 parts in sequence, for example: 1 (sampling marker) - `BASE64 encoded TraceId` - `BASE64 encoded parent trace segment ID` - `parent span ID` - `BASE64 encoded parent service name` - `BASE64 encoded parent service instance` - `BASE64 encoded parent endpoint` - `BASE64 encoded destination address`.

[0111] During the conversion, the TraceId extracted from B3 can be mapped to the second part of SW8, and the extracted SpanId can be mapped to the fourth part (parent span ID). The parent trace segment ID, parent service, parent service instance, parent endpoint, and target address are filled in according to the configuration and network information of the node where the current adapter is located.

[0112] Step S14, Injection and Transmission: The newly generated complete SW8 protocol header string is injected into the header of the original HTTP request, replacing or overwriting the original B3 header. Subsequently, the request is forwarded to the downstream Java business service. The SkyWalking proxy in the Java service can directly recognize the SW8 header and continue to build and report sub-spans based on this context, thereby seamlessly extending the call chain originating from the PHP service into the Java service.

[0113] Secondly, the SW8 to B3 protocol adapter, deployed at the entry point of the second protocol environment (such as a PHP service), handles inbound requests originating from the first protocol environment. This adapter can exist as a web server module or standalone middleware. Its workflow specifically includes:

[0114] Step S21, Identification and Decoding: The adapter intercepts the HTTP request and identifies whether the SW8 protocol header exists.

[0115] Step S22, Extraction and Mapping: The adapter decodes the SW8 header to restore the key context information encoded therein, such as the global tracking identifier and the parent span identifier.

[0116] Step S23, Transformation and Reconstruction: The adapter maps and reconstructs the decoded information into the HTTP header fields corresponding to the Zipkin B3 protocol. For example, a common format of the B3 protocol is `{TraceId}-{SpanId}-{SamplingDecision}-{ParentSpanId}`. During reconstruction, the trace identifier extracted from SW8 can be used as the B3 TraceId, the parent span identifier extracted from SW8 can be used as the B3 ParentSpanId, and a default SpanId (such as 0) and sampling decision can be generated for the current request.

[0117] Step S24, Injection and Transmission: The refactored B3 standard header fields are injected into the PHP server's global variables or request object. The Zipkin client integrated within the PHP application will automatically capture these headers and use them as a valid parent context to create the current request span, thus seamlessly extending the chain initiated by the Java service into the PHP service. Through the collaborative work of the bidirectional adapters described above, automatic conversion and transmission of the chain context between the two heterogeneous tracing standards are achieved.

[0118] Furthermore, to overcome the problem of insufficient data collection depth in existing link data collection in second protocol environments (such as PHP), this application implements a semantic enhancement collection mechanism based on protocol conversion. This mechanism automatically collects detailed semantic information at key call points by customizing and enhancing the core components of the PHP application framework.

[0119] The semantic enhancement collection specifically includes the following implementation aspects: First, for HTTP client calls, the enhancement point is located in the framework's HTTP client component. Step S31, call interception and context injection: Before initiating an external HTTP request, the request construction process is intercepted, and a standard B3 format header is automatically generated from the current active link context and injected into the request. Step S32, call metadata capture: In the reported span, the target address and request method of this call are synchronously recorded as semantic tags. Step S33, selective capture of request parameters: According to the configuration strategy, query parameters or de-identified request body summaries can be selectively recorded.

[0120] Secondly, regarding database operations, enhancements are focused on the database connection and query execution components. Step S34, SQL execution interception: An interceptor is inserted before query execution. Step S35, SQL semantic extraction and recording: The original SQL statement is extracted, parameterized to generate a templated statement, and the database identifier is recorded. Step S36, performance metric association: The execution time of the query is recorded and reported in association with the SQL template.

[0121] Thirdly, for command-line task execution, the enhancement point is located at the command-line application entry point. Step S40, Root Span Creation: At the script execution entry point, create a root span representing this task execution. Step S41, Execution Parameter Recording: Record the executed script identifier and the passed command-line parameters as attribute data for this root span.

[0122] The above approach enables fine-grained observation of the critical internal operations of PHP services, thereby achieving the same level of observability depth as the first protocol environment in the merged end-to-end view.

[0123] and Figure 1 Corresponding to the method described above, embodiments of this application also provide a service link tracing system for... Figure 1 The specific implementation of the method is shown in the following structural diagram: Figure 4 As shown, it includes:

[0124] The identification unit 401 is used to identify the link tracing context information of the first protocol carried in the service call request in response to receiving a service call request from the first protocol environment.

[0125] The conversion unit 402 is used to convert the link tracing context information of the first protocol in the service call request into link tracing context information conforming to the second protocol to obtain the target request;

[0126] The first execution unit 403 is used to send the target request to the target service in the second protocol environment so that the target service can perform the business operation corresponding to the target request.

[0127] The second execution unit 404 is used to collect semantic data associated with the business call operation based on the link tracing context information of the second protocol when at least one preset type of business call operation is detected during the execution of business operations in the target service, so as to form enhanced link tracing information containing semantic data.

[0128] In one embodiment provided in this application, based on the above-described solution, optionally, the conversion unit includes:

[0129] Extraction sub-unit, used to extract the global tracking identifier and the current span identifier from the link tracing context information of the first protocol;

[0130] The mapping subunit is used to map the global tracking identifier to a tracking identifier in the second protocol format, and to map the current span identifier to the parent span identifier in the second protocol format;

[0131] The generation sub-unit is used to assemble the mapped tracking identifier, parent span identifier, and preset service metadata according to the specification structure of the second protocol to generate the second protocol link tracing context information.

[0132] This application also provides an electronic device, the structural schematic diagram of which is shown below. Figure 5 As shown, it specifically includes a memory 501 and one or more instructions 502, wherein one or more instructions 502 are stored in the memory 501 and are configured to be executed by one or more processors 503 to perform the above-mentioned communication tunnel establishment method.

[0133] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0134] Finally, it should be noted that in this paper, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0135] For ease of description, the above system is described by dividing it into various functional units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0136] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of the embodiments of this application.

[0137] The solution provided in this application has been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A service link tracing method, characterized by, include: In response to receiving a service call request from a first protocol environment, the link tracing context information of the first protocol carried in the service call request is identified; The link tracing context information of the first protocol in the service call request is converted into link tracing context information conforming to the second protocol to obtain the target request; The target request is sent to the target service in the second protocol environment so that the target service performs the business operation corresponding to the target request; During the execution of business operations by the target service, when at least one preset type of business call operation is detected, semantic data associated with the business call operation is collected based on the link tracing context information of the second protocol to form enhanced link tracing information containing the semantic data. When the preset type of business call operation includes an HTTP call, the collection of semantic data associated with the business call operation includes: when an HTTP call is detected in the business operation, converting the link tracing context information of the second protocol into a format suitable for HTTP propagation and injecting it into the request header of the HTTP call; capturing the target address and request method of the HTTP call; collecting the target address and request method as semantic data; and selectively recording the query parameters or the anonymized request body summary of the HTTP call according to the configuration strategy. When the business call operation of the preset type includes a database query operation, the collection of semantic data associated with the business call operation includes: when a database query operation is detected in the business operation, obtaining the original query statement to be executed; parameterizing the original query statement to generate a templated query statement; and collecting the templated query statement and the corresponding database identifier as semantic data.

2. The method of claim 1, wherein, The step of converting the link tracing context information of the first protocol in the service call request into link tracing context information conforming to the second protocol includes: Extract the global tracking identifier and the current span identifier from the link tracing context information of the first protocol; Map the global tracking identifier to a tracking identifier in the second protocol format, and map the current span identifier to a parent span identifier in the second protocol format; According to the specification structure of the second protocol, the mapped tracking identifier, parent span identifier, and preset service metadata are assembled to generate the second protocol link tracing context information.

3. The method according to claim 1 or 2, characterized in that, The method further includes: Record the execution time of the database query operation; The execution time is collected as semantic data.

4. The method of claim 2, wherein, When the service call request is a command-line task, the method further includes: At the command-line task execution entry point, create a root span based on the second protocol link tracing context information; Get the script identifier and input parameters of the current command-line task; The script identifier and the input parameters are recorded as attribute data for the root span.

5. A service link tracing apparatus characterized by comprising: include: The identification unit is configured to, in response to receiving a service call request from a first protocol environment, identify the link tracing context information of the first protocol carried in the service call request; The conversion unit is used to convert the link tracing context information of the first protocol in the service call request into link tracing context information conforming to the second protocol to obtain the target request; The first execution unit is used to send the target request to the target service in the second protocol environment, so that the target service performs the business operation corresponding to the target request; The second execution unit is used to collect semantic data associated with the business call operation based on the link tracing context information of the second protocol when at least one preset type of business call operation is detected during the execution of business operations by the target service, so as to form enhanced link tracing information containing the semantic data. The second execution unit is specifically configured to: when the preset type of business call operation includes an HTTP call, the collection of semantic data associated with the business call operation includes: when an HTTP call is detected in the business operation, converting the link tracing context information of the second protocol into a format suitable for HTTP propagation and injecting it into the request header of the HTTP call; capturing the target address and request method of the HTTP call; collecting the target address and request method as semantic data, and selectively recording the query parameters or the de-identified request body summary of the HTTP call according to a configuration strategy; When the business call operation of the preset type includes a database query operation, the collection of semantic data associated with the business call operation includes: when a database query operation is detected in the business operation, obtaining the original query statement to be executed; parameterizing the original query statement to generate a templated query statement; and collecting the templated query statement and the corresponding database identifier as semantic data.

6. The apparatus of claim 5, wherein, The conversion unit includes: The extraction subunit is used to extract the global tracking identifier and the current span identifier from the link tracing context information of the first protocol; The mapping subunit is used to map the global tracking identifier to a tracking identifier in the second protocol format, and to map the current span identifier to a parent span identifier in the second protocol format; The generation sub-unit is used to assemble the mapped tracking identifier, parent span identifier, and preset service metadata according to the specification structure of the second protocol to generate the second protocol link tracing context information.

7. A storage medium, characterized by The storage medium includes storage instructions, wherein, when the instructions are executed, the device where the storage medium is located is controlled to perform the service link tracing method as described in any one of claims 1 to 4.

8. An electronic device, comprising: It includes a memory, and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors as described in any one of claims 1 to 4.

Images