Workflow tracking method and apparatus

Abstract

Embodiments of the present application provide a workflow tracking method. The method aggregates all spans in a Trace to a node, and reports in the granularity of the Trace, thereby realizing atomicity of the Trace, ensuring integrity of the Trace, and improving accuracy of the Trace.

Description

Technical Field

[0001] This application relates to the field of cloud computing, and more particularly to a workflow tracing method and apparatus. Background Technology

[0002] In serverless computing, functions are the basic computational units. Currently, performance troubleshooting in serverless workflows primarily employs distributed tracing techniques; however, existing distributed tracing techniques suffer from additional performance overhead and accuracy issues. Summary of the Invention

[0003] This application provides a workflow tracing method and apparatus. In this method, the spans of compute nodes are aggregated onto a single node and reported at the Trace level, ensuring the atomicity of the Trace.

[0004] Firstly, this application provides a workflow tracing method. This method is applied to a first node and includes: acquiring at least one span (Span) for each computational unit in the workflow and placing the acquired Span in a reporting queue; wherein the Span is used to track the execution status of the corresponding computational unit when executing its corresponding function. If the reporting queue meets the reporting conditions, the reporting queue is transmitted to the tracing device; wherein the reporting conditions instruct the reporting queue to use the tracing link Trace as the reporting granularity, and the Trace includes all Spans generated by the same request in the workflow. Thus, by aggregating all Spans in the Trace to one node for reporting, this application effectively avoids the problem of Span loss caused by independent reporting by computational units. Furthermore, the first node aggregating the Spans reports at the Trace granularity to avoid inaccuracies in the reconstructed Trace due to missing Traces. By using the Trace as the reporting granularity, this application ensures the atomicity of the Trace, i.e., there will be no incomplete Traces, which can effectively improve the accuracy of the backend reconstructed Trace.

[0005] In one possible implementation, the method further includes discarding all Spans in the reporting queue if the reporting conditions are not met. Thus, this application uses Trace as the reporting granularity. If the reporting granularity is not met, the entire queue is discarded, achieving atomicity in Trace reporting. That is, an operation is indivisible and complete; it either succeeds entirely or fails entirely, with no partial execution. This effectively improves the accuracy of backend Trace reconstruction.

[0006] In one possible implementation, each Span's data includes key information, which includes at least one of the following: Span height information, Span time information, and Span identification information; wherein, the height information is used to indicate the calling relationship of the corresponding computational unit in the workflow. Thus, this application can obtain the dependency relationship between Spans through the height information, where the Span dependency relationship can also be understood as the calling relationship between corresponding computational units. By setting the height information, the bandwidth consumption of Span context information can be reduced. Especially in the interaction process of asynchronous nodes or microservice architectures, it can effectively reduce network amplification effects.

[0007] For example, a Span can include a platform class Span and a user class Span. The platform class Span can include key information, or key information and other information. The user class Span includes key information and other information.

[0008] In one possible implementation, at least one Span is sent after being pruned by the corresponding computing unit based on pruning conditions, which indicate whether any abnormalities have occurred in the execution of the corresponding computing unit. Thus, by pruning some normal Spans, this application can further reduce the bandwidth usage of Spans, thereby further mitigating network amplification effects.

[0009] For example, pruning conditions could mean pruning normal platform spans while not pruning abnormal platform spans. This means retaining their key data and other information to be reported to the tracking device.

[0010] In one possible implementation, information other than key information in the Span that meets the pruning conditions is discarded; the key information includes at least one of the following: the Span's height information, the Span's time information, and the Span's identification information. Optionally, the Span that meets the pruning conditions may be a normal platform-type Span, i.e., a Span that can be pruned.

[0011] In one possible implementation, the first node is a scheduling node. Before acquiring at least one Span for each computational unit in the workflow, the method includes: sending a call request to a single computational unit, the call request instructing the single computational unit to execute a corresponding function; and receiving a call response from the single computational unit, the call response including the execution result of the single computational unit and at least one Span. In this way, this application can aggregate traces through the calling node and report them to the tracing device.

[0012] In one possible implementation, the first node is one of the computational units in the workflow. Each computational unit in the workflow sends its own generated Span, or its own generated Span and the Span received by that computational unit, to the first node. In this way, when asynchronous nodes or other systems exist in the system, traces can be aggregated through any computational unit to achieve aggregated reporting.

[0013] Secondly, this application provides a workflow tracing device applied to a first node, comprising: an organization module, configured to acquire at least one span (Span) of each computational unit in the workflow and place the acquired Span in a reporting queue; wherein the Span is used to track the execution status of the corresponding computational unit when executing the corresponding function; and a reporting module, configured to transmit the reporting queue to the tracing device if the reporting queue meets the reporting conditions; wherein the reporting conditions are used to instruct the reporting queue to use the tracing link Trace as the reporting granularity, and the Trace includes all Spans generated by the same request in the workflow.

[0014] In one possible implementation, the reporting module is also used to discard all Spans in the reporting queue if the reporting queue does not meet the reporting conditions.

[0015] In one possible implementation, the data of each Span includes key information, which includes at least one of the following: the height information of the Span, the time information of the Span, and the identification information of the Span; wherein, the height information is used to indicate the calling relationship of the calculation unit corresponding to the Span in the workflow.

[0016] In one possible implementation, at least one Span is sent by the corresponding computing unit after pruning based on pruning conditions, which are used to indicate whether the execution of the corresponding computing unit has encountered any abnormalities.

[0017] In one possible implementation, information other than key information in a Span that meets the pruning conditions is discarded; the key information includes at least one of the following: the height information of the Span, the time information of the Span, and the identification information of the Span.

[0018] In one possible implementation, the first node is a scheduling node, and the device further includes a calling module for: sending a calling request message to a single computing unit, the calling request message being used to instruct the single computing unit to execute a corresponding function; and receiving a calling response message sent by the single computing unit, the calling response message including the execution result of the single computing unit and at least one Span.

[0019] In one possible implementation, the first node is one of the computational units in the workflow, wherein the computational unit in the workflow sends its own generated Span, or its own generated Span and the Span received by the computational unit, to the first node.

[0020] Thirdly, embodiments of this application provide a computer-readable medium for storing a computer program, the computer program including instructions for performing the method in the first aspect or any possible implementation of the first aspect.

[0021] Fourthly, embodiments of this application provide a computer program including instructions for performing the method in the first aspect or any possible implementation thereof.

[0022] Fifthly, embodiments of this application provide a chip including a processing circuit and transceiver pins. The transceiver pins and the processing circuit communicate with each other via an internal connection path. The processing circuit executes the method in the first aspect or any possible implementation of the first aspect to control the receiving pin to receive signals and to control the transmitting pin to transmit signals.

[0023] In a sixth aspect, embodiments of this application provide a distributed tracking system, which includes a first node, multiple computing nodes, and a tracking device as described in the first aspect above. Attached Figure Description

[0024] Figure 1 This is a schematic diagram illustrating a serverless workflow;

[0025] Figure 2a This is a flowchart illustrating a synchronous execution strategy as an example.

[0026] Figure 2b This is a flowchart illustrating an asynchronous execution strategy as an example.

[0027] Figure 2c This is a flowchart illustrating an asynchronous execution strategy as an example.

[0028] Figure 3 This is a schematic diagram illustrating the process of distributed tracing as an example.

[0029] Figure 4a This is a schematic diagram illustrating the synchronous reporting process as an example.

[0030] Figure 4b This is a schematic diagram illustrating an asynchronous reporting process;

[0031] Figure 5 A flowchart illustrating the workflow tracing method provided in this application;

[0032] Figure 6 This is a schematic diagram illustrating the differential tracking process as an example.

[0033] Figure 7 This is a schematic diagram of the reporting queue as an example;

[0034] Figure 8 This is a schematic diagram illustrating the Trace reconstruction process as an example.

[0035] Figure 9 This is a schematic diagram illustrating the execution flow of a computing unit as an example.

[0036] Figure 10 This is a schematic diagram illustrating the call flow as an example.

[0037] Figure 11 This is a schematic diagram illustrating the execution flow of a computing unit as an example.

[0038] Figure 12 This is a schematic diagram illustrating the call flow as an example.

[0039] Figure 13 This is a schematic diagram illustrating an exemplary workflow tracing method;

[0040] Figure 14 The diagram illustrates the structure of the device as an example.

[0041] Figure 15 This is an exemplary structural diagram of the device. Detailed Implementation

[0042] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0043] To better illustrate the technical solutions in this application, a brief explanation of some background technologies that may be involved is provided first:

[0044] Serverless computing:

[0045] Serverless computing is a paradigm of cloud computing that, compared to traditional cloud applications, offers greater ease of deployment, elastic scalability, and more granular billing models. Those skilled in the art abstract business logic into functions, package these functions and their dependencies into container images, and then upload the container images to the platform. When a function needs to be invoked, the cloud platform (also known as a cloud computing platform) starts a container based on the invocation request to run the corresponding function.

[0046] Serverless workflow:

[0047] Serverless workflow, or simply workflow, provides a way to combine different functions to build more complex applications and is the cornerstone of building large-scale serverless applications.

[0048] Figure 1 This is an exemplary diagram of a serverless workflow, such as... Figure 1 As shown, after function A completes its execution, function B obtains the data from function A (which in this embodiment can also be referred to as execution data, execution results, etc., and this application does not limit this). Then, function B continues to perform corresponding operations or calculations based on the execution result of A. Finally, the execution result of function B is returned to the user.

[0049] Generally, dependencies between functions are defined by a Directed Acyclic Graph (DAG). A DAG is a graph structure consisting of a set of vertices (which can be understood as functions) and a set of directed edges, where the direction of the edges indicates the relationship between functions, and there are no paths forming cycles in the graph. In this embodiment, the vertices in the DAG may optionally be functions; this can be understood as the workflow described in this embodiment being a way to combine different functions to build more complex applications. The edges between vertices represent the (data dependency) relationship between functions. Figure 1 Taking a DAG as an example, the relationship between function A and function B is as follows: function B depends on function A, or it can be understood that function A needs to call function B, that is, the return value of A (which can be called the execution result in this embodiment) is used as the input of B.

[0050] function:

[0051] Also known as computer programs, computer code, or execution logic, functions are the basic units of operation in serverless computing. These programs are pieces of code uploaded by users, which must define an entry point function. When the serverless platform receives a request to call a function, the platform starts a container and runs the entry point function.

[0052] Computational unit:

[0053] In this embodiment, the computing unit is a resource provided by the serverless system to support the execution of the workflow. For example, the computing unit can be a component (e.g., CPU) or a server; this application does not limit this. Specifically, a computing unit can run a function (or a portion of a function). It can be understood that computing units and functions correspond, and each function in the workflow requires the corresponding computing unit to execute. It can also be understood that a function is a static program, and each device or node can run the corresponding function through one or more computing units (e.g., components) to achieve the corresponding functionality.

[0054] Scheduling node:

[0055] When a distributed system (such as the Serverless platform in this embodiment) runs multiple functions simultaneously, a scheduling node will uniformly schedule the functions according to their dependencies. Typically, the scheduling node is also called the coordinator.

[0056] Optionally, the technical solutions in the embodiments of this application can be applied to systems with scheduling nodes or systems without scheduling nodes, and this application does not limit them.

[0057] Distributed tracing:

[0058] A distributed system performance analysis tool (which can be simply called a distributed tracing tool) that is widely used in the cloud provides users with an overall end-to-end view that reflects the work execution status of each computing unit in the workflow by recording the execution time and related execution information of each computing unit.

[0059] To enable Serverless users to determine the workflow's status, distributed tracing technology is needed to monitor the workflow's working state within the Serverless platform and user functions. In this embodiment, the execution status of a function is the execution status of its corresponding computing unit. Correspondingly, the workflow's working state is the execution status of each computing node supporting the workflow. Optionally, the workflow execution status can also be referred to as workflow execution status, workflow running status, execution status, etc., and this application does not impose any limitations.

[0060] The distributed tracing tool in this application embodiment can be deployed on various computing units and scheduling nodes. The device in this application embodiment can be a cloud server, or other computer devices or servers; this application does not impose any limitations. The distributed tracing tool may include, but is not limited to, a tracing data module, a pruning module, an organization module, and a buffer module.

[0061] The tracking data module, deployed within the distributed tracking tool, is used to acquire and record the execution status data of each computing unit in the workflow. This data includes, but is not limited to, the execution time of the computing unit and related information (such as request return values, status codes, etc.). The tracking data describes the execution status of the corresponding computing unit, thus enabling the tracking of the execution status of each computing unit.

[0062] Trace pruning module: Deployed within the distributed tracing tool, it is used to prune Spans.

[0063] Trace grouper: This module organizes the spans returned by each function call and places them in a buffer module to maintain the causal relationship between spans.

[0064] The Span buffer module is located on the central scheduling node and is used to temporarily store the Spans returned by various function calls.

[0065] The reporting module serializes the entire buffer and reports the data.

[0066] Span:

[0067] In distributed tracing, the smallest unit of execution is used to describe (or indicate) the execution of a piece of code. In the embodiments of this application, a Span is the tracing data of a computing unit. A Span can generate corresponding tracing data based on the working execution status of the corresponding computing unit (or component, more specifically, a piece of code being monitored).

[0068] For example, tracking data, also known as Span Data, includes, but is not limited to, key information such as the context information of the Span, the time information of the Span, and the identification information of the Span. It may also include other information, such as, but not limited to, "annotations," "tags," and "attributes." Among them, the time information of the Span is used to indicate the execution time of the computing unit monitored by the Span.

[0069] In this embodiment, each computing unit generates a corresponding Span after receiving a call request. After the computing unit finishes execution, the Span ends its monitoring of that computing unit and generates corresponding Span Data. That is, the start time of the Span is usually the time when the computing unit begins executing its function (i.e., when it receives the call request), and the end time of the Span is usually the time when the computing unit finishes executing its function. Optionally, the Span's time information can also be understood as the duration between the start and end of the Span's monitoring. Of course, in some instances, the time nodes for the job execution duration can also be set according to actual needs; this application does not impose any limitations.

[0070] In one possible implementation, the context information of a Span includes, but is not limited to, a Trace ID, a Span ID, and its parent Span ID. The Trace ID determines whether a Span belongs to the same request as other Spans, or whether they belong to the same Trace. The Span ID and its parent Span ID determine the calling relationship (i.e., dependency relationship) between two Spans. Optionally, the asynchronous execution computation unit in this embodiment may use this type of context information.

[0071] In another possible implementation, the context information of the Span includes, but is not limited to, height information. Height information indicates the height of the Span within the Trace, which can also be understood as indicating the depth of the computational unit corresponding to the Span in the workflow, or as indicating the dependencies of the functions executed by the computational unit corresponding to the Span. Specific settings will be described in the following embodiments and will not be elaborated here. Optionally, the synchronous execution computational unit in this application embodiment can use this type of context information.

[0072] Optionally, the identification information of a Span may include, but is not limited to, at least one of the following: Span ID (e.g., the name of the Span), etc.

[0073] Trace (tracing link):

[0074] All spans generated by the same request (e.g., referred to as a user request in this embodiment) provide an end-to-end view of that request within the distributed system. This can be understood as follows: after receiving a request, the system initiates a workflow in response. Each computational unit in the workflow begins execution and generates a corresponding span. The spans generated by all computational units in the workflow constitute a trace corresponding to that request.

[0075] In this embodiment, the system can receive multiple requests, each corresponding to a Trace. A Trace includes multiple Spans. This can be understood as each Span in a Trace being used to monitor the execution status of the corresponding component when the request corresponding to that Trace is run. This embodiment only illustrates a single-user request scenario; in a multi-user request scenario, the processing method for each user request's corresponding Span is the same, and this application will not provide detailed examples for each.

[0076] process:

[0077] A process is a "software resource" provided by the operating system. It is an abstraction of a running program by the operating system. A process can be viewed as a single execution of a program (i.e., a function). A process exists because it depends on the program to run. A process is dynamic, while a program (i.e., a function) is static.

[0078] Threads:

[0079] Threads, also known as lightweight processes, are improvements upon processes, maintaining independent scheduling and execution. This concurrency support eliminates the overhead of allocating and releasing resources. For example, a process can include one or more threads.

[0080] Optionally, each computing unit (e.g., component) can run one process. Each process can enable one or more threads. In the embodiments of this application, the relationship between a process and a function can be viewed as a one-to-one relationship, that is, one process represents one function. Optionally, one function can embed multiple functions, that is, one function can include multiple (or multiple segments) of functions, or it can be understood that one function can include one or more segments of code, and each segment of code can be regarded as an execution logic.

[0081] In this embodiment, a computing unit can execute one or more execution logics, and each execution logic generates a corresponding Span. A computing unit can have multiple Spans. A Span can be used to monitor the execution status of the computing unit when it runs an execution logic (i.e., a piece of code in a function).

[0082] The computing unit described in this application embodiment is illustrated using a component as an example. In different scenarios, the computing unit may also refer to a server (or computer device) in a distributed system, and one or more components may be deployed in the server. The computing unit may also refer to a CPU or the chip to which the CPU belongs; this application does not impose any limitations.

[0083] Synchronous execution strategy, asynchronous execution strategy:

[0084] In the embodiments of this application, the workflow execution strategy of the computing unit (referring to the strategy for function calls) may include, but is not limited to, synchronous call strategy or asynchronous execution strategy.

[0085] Optionally, the computing unit executing the synchronous execution strategy can be called a synchronous computing unit, and the computing unit executing the asynchronous execution strategy can be called an asynchronous computing unit. The computing units in the system (or node) can all be synchronous computing units, all be asynchronous computing units, or some can be synchronous computing units and the other part can be asynchronous computing units; this application does not impose any limitations.

[0086] Figure 2a This is a flowchart illustrating an exemplary synchronous execution strategy. The synchronous execution strategy may optionally be: after receiving a request, a node begins executing a function and then sends a response upon completion. Please refer to... Figure 2a The scheduling node receives a user request to execute a workflow. The scheduling node (or other computing unit that calls the computing unit; this example only uses the serverless scheduling node method) sends a call request to computing node 1. After receiving the scheduling request from the scheduling node, computing unit 1 executes the corresponding function. After execution, it sends a scheduling response to the scheduling node, which includes, but is not limited to, the execution result of computing unit 1. The scheduling node 1 then sends a scheduling request to computing unit 2, which includes, but is not limited to, the execution result of computing unit 1. Computing unit 2 executes the corresponding function, where the execution result of computing unit 1 is used as the function input. After execution, computing unit 2 sends a scheduling response to the scheduling node, which includes, but is not limited to, the execution result of computing unit 2. Optionally, the system may also contain one or more nodes or units that are not scheduled by the calling node, such as user nodes (e.g., gateway devices). User nodes can be used to send user requests to the scheduling node. In some instances, user nodes may also deploy distributed tracing tools to generate corresponding Spans, which can report the Spans to the scheduling node in an asynchronous reporting manner as described in the embodiments below; these details are not elaborated here.

[0087] Figure 2b This is a flowchart illustrating an asynchronous execution strategy. The asynchronous execution strategy may optionally involve a node receiving a request, responding, and then executing the function. For example, consider the asynchronous execution of a scheduling node. Figure 2bThe scheduling node receives a user request to execute a workflow. Responding to the user request, the scheduling node sends a user response. The scheduling node then sends a call request to compute node 1. Upon receiving the scheduling request, compute node 1 executes the corresponding function. After execution, it sends a scheduling response to the scheduling node, which includes, but is not limited to, the execution result of compute node 1. The scheduling node 1 then sends a scheduling request to compute node 2, which includes, but is not limited to, the execution result of compute node 1. Computational node 2 executes the corresponding function, with the execution result of compute node 1 serving as the function input. After execution, compute node 2 sends a scheduling response to the scheduling node, which includes, but is not limited to, the execution result of compute node 2.

[0088] Of course, in some instances, compute nodes can also execute asynchronous execution strategies. For example... Figure 2c As shown, after receiving a scheduling request from the scheduling node, computing unit 1 sends a scheduling response back to the scheduling node. Computing unit 1 starts a new thread to execute the corresponding function. After execution, computing unit 1 sends a scheduling request to computing unit 2, which includes the execution result of computing unit 1. In response to the received scheduling request, computing unit 2 sends a scheduling response back to computing unit 1. Computing unit 2 then executes the corresponding function. Computing unit 2 can report the execution result to the user.

[0089] For example, existing distributed tracing technologies inherently involve a trade-off between additional performance overhead and message accuracy. Specifically, performance overhead refers to the additional performance overhead incurred by the tracing system on the application, such as increased request latency; theoretically, lower request latency is better. Accuracy refers to whether the spans are complete, i.e., whether any spans are missing; theoretically, more complete spans are better. However, the more complete the span records, the greater the overhead incurred in recording them, introducing a trade-off between performance and accuracy. Furthermore, compared to microservice architectures, Serverless introduces more platform-layer components, resulting in more data requiring the collection of distributed tracing technologies, further amplifying the performance-accuracy balance issue.

[0090] For example, existing distributed tracing tools collect data on the performance of each component and generate corresponding Spans (i.e., tracing data). The distributed tracing tool then reports these Spans at its respective computing unit to a centralized distributed tracing backend (which in this embodiment may be called a tracing device, and could be a collection of one or more servers or computer devices) for data storage and analysis.

[0091] Figure 3 For an illustrative example of a distributed tracing process, please refer to... Figure 3For example, suppose a distributed system consists of computing unit 1, computing unit 2, and computing unit 3 (e.g., three servers), and each computing unit is equipped with a distributed tracing tool to collect the execution status of each computing unit. Computing unit 1 responds to a received request (e.g., a scheduling request sent by a scheduling node) and begins executing the corresponding function. During the execution of the function by the computing unit, the distributed tracing tool collects the execution status of the corresponding node and generates the corresponding Span. For example, computing unit 1 generates Span1 to Span3, computing unit 2 generates Span4 to Span6, and computing unit 3 generates Span7 to Span9; the number is only illustrative and not limited in this application. Existing distributed tracing tools use a computing unit reporting method, where each computing unit reports its own Span to the tracing device.

[0092] The reporting methods of computing units (i.e., the distributed tracing tools deployed on the computing units) can include, but are not limited to, synchronous reporting strategies or asynchronous reporting strategies. Among these, a synchronous reporting strategy may optionally mean that the request can only resume execution after the tracing data has been uploaded to the backend, i.e., as shown below. Figure 4a The process is shown below. An asynchronous reporting strategy may optionally include a reporting queue for batch reporting.

[0093] Figure 4a For an illustrative example of the synchronous reporting process, please refer to... Figure 4a When the function monitored by Span1 of computing unit 1 (e.g., a piece of code) completes execution, computing unit 1 reports Span1 to the tracking device. After reporting is complete (e.g., receiving a confirmation message from the tracking device), computing unit 1 continues to execute the next piece of code (the executed component may be the same or a different component; this application does not limit this), and generates Span2. Computing unit 1 reports Span2 to the tracking device. After reporting is complete, computing unit 1 continues to execute the next piece of code, and generates Span3. Computing unit 1 reports Span2 to the tracking device.

[0094] Figure 4b For an illustrative example of the asynchronous reporting process, please refer to... Figure 4b Each computation unit corresponds to a reporting queue. Taking computation unit 1 as an example: After computation unit 1 completes its execution and generates Span1, it places Span1 in the reporting queue. Computation unit 1 continues to execute the next piece of code and generates Span2, placing Span2 in the reporting queue. Computation unit 1 continues to execute the next piece of code and generates Span3, placing Span3 in the reporting queue. Optionally, if the reporting queue is full (i.e., the reporting queue length reaches a threshold), the earlier data in the time series will be discarded to save memory. For example, ... Figure 4b As shown, compute node 1 may discard Span1. The processing of other compute units is the same, and will not be described in detail here.

[0095] Optionally, the reporting method of the reporting queue can be periodic or trigger-based. For example, the reporting queue reports to the tracking device at a preset period, such as the calculation unit 1 transmitting the reporting queue to the tracking device at regular intervals. Optionally, trigger-based reporting can occur when the reporting queue reaches a preset length. For example, the calculation unit 1 places a Span in the reporting queue, and after the reporting queue reaches its preset length, it reports each Span in the queue. After each reporting session, the reporting queue is cleared to buffer subsequently received Spans.

[0096] In one possible implementation, computing unit 1 can run process 1, which includes threads 1 through 3. Span1-1 through Span1-n are used to monitor the execution status of each component running thread 1, Span2-1 through Span2-n are used to monitor the execution status of each component running thread 2, and Span3-1 through Span3-n are used to monitor the execution status of each component running thread 3. For example, Span1-1 describes the execution status of a section of code in the function corresponding to thread 1 by component 1. After each thread is completed, the computing unit adds at least one corresponding Span (e.g., Span1-1 through Span1-n) to the reporting queue.

[0097] In existing technologies, the limited queue length leads to incomplete traces, meaning spans are sometimes discarded, resulting in lower accuracy of the traces analyzed by the tracing device. For example, the loss of some important spans prevents users from analyzing workflow problems based on the current trace results. However, increasing the queue length to improve accuracy incurs additional overhead. While synchronous reporting, which reports spans one by one, offers higher accuracy, its frequent reporting consumes bandwidth, causing additional overhead. This is especially problematic when dealing with large amounts of tracing data, i.e., a large number of spans, as the computational units need to frequently perform distributed reporting, hindering the performance of function workflow execution.

[0098] Figure 5 Please refer to the flowchart of the workflow tracing method provided in this application. Figure 5 Specifically, including but not limited to the following steps:

[0099] S501, the first node obtains at least one span (Span) for each computational unit in the workflow and places the obtained Span in the reporting queue. The Span is used to track the execution status of the corresponding computational unit.

[0100] For example, a scheduling node in a distributed system (such as the first node in this application, or the central node, which is not limited in this application) receives a request (also called a workflow request, scheduling request, execution request, or user request, which is not limited in this application), which is used to call a relevant function. The workflow corresponding to the request in the distributed system will respond to the call, and each computing unit in the workflow will execute the corresponding function.

[0101] The first node in this embodiment can be a scheduling node in the system. Optionally, the first node in this embodiment can also be an intermediate computing unit in the system, that is, any computing unit in the workflow other than the scheduling node. It can be set according to actual needs, and this application does not limit it.

[0102] Specifically, in this embodiment, the invocation of computation units in the workflow can include, but is not limited to, synchronous and asynchronous methods. Detailed descriptions can be found above and will not be repeated here. Correspondingly, computation units can also be divided into synchronous computation units and asynchronous computation units. Optionally, a distributed system may include synchronous computation units and / or asynchronous computation units, that is, all of them may be synchronous computation units, or all of them may be asynchronous computation units, or some may be synchronous computation units and the other part may be asynchronous computation units.

[0103] In this embodiment, each computational unit in the workflow executes its corresponding function according to its workflow sequence (e.g., the order of the directed acyclic graph described above). Specifically, if it is a synchronous computational unit, it executes its corresponding function in response to a call from the scheduling node. If it is an asynchronous computational unit, the computational unit calls the next computational unit; that is, in the workflow, after the previous computational unit completes its execution, it sends a call request to the next computational unit, and the call request includes, but is not limited to, the execution result of that computational unit. The next computational unit, in response to the received call request, uses the execution result of the previous computational unit as input and executes its corresponding function.

[0104] For example, during workflow execution, each computing unit generates a corresponding Span after receiving a call request. That is, after receiving a call request from a computing unit, the Span begins monitoring the execution status of that unit to generate corresponding Span Data (i.e., tracking data). Span Data includes, but is not limited to: Span identification information, Span time information, Span context information, and other data, including but not limited to: annotations, tags, and attributes.

[0105] In this embodiment of the application, each computing unit reports its own Span to one of the computing units, namely the first node described in this embodiment of the application.

[0106] In one example, if the distributed system corresponds to a synchronous execution strategy, after the computing unit receives the call request from the scheduling node, it executes the corresponding function. After the corresponding function is completed, it sends a call response back to the scheduling node. The call response includes, but is not limited to, at least one Span generated by the computing unit.

[0107] In another example, if the distributed system corresponds to an asynchronous execution strategy (the corresponding description can be found above and will not be repeated here), after a computing unit receives a call request from a previous computing unit (which may also be a scheduling node), it sends a call response to the previous computing unit (which may also be a scheduling node). Subsequently, the computing unit may optionally start a new thread and execute the corresponding function. That is, in this example, after the asynchronous computing unit completes the function execution, it will not send a call response back to the previous computing unit. Accordingly, in this example, when the asynchronous computing unit sends a call request to the next computing unit, it carries the Span generated by this computing unit and the Span received from the previous computing unit in the call request and sends it to the next computing unit. In this way, the next computing unit receives the Spans from each computing unit in the workflow that precedes it. In the case of a scheduling node or computing unit with an asynchronous execution strategy, the first node to perform aggregation and reporting of the Span may be the scheduling node or other computing units.

[0108] In one possible implementation, after each computing unit generates a Span, a differential tracing process can be performed on the Span. Specifically, differential tracing may optionally determine whether pruning can be performed on the Span Data. In this embodiment, functions can be divided into two categories: system functions (also known as Serverless platform functions) and user functions, i.e., user-defined functions. Correspondingly, computing nodes can also be divided into user-class computing nodes and platform-class computing nodes. Similarly, the corresponding Spans can also be divided into platform-class Spans or user-class Spans. It can be understood that platform-class Spans are used to monitor the execution status of platform-class computing nodes when running platform functions. User-class Spans are used to monitor the execution status of user-class computing nodes when executing user functions.

[0109] In one example of this application's embodiments, for the user class Span, the computing unit retains all SpanData of the Span, meaning that what is reported to the tracking device is all SpanData of the Span. In another example, for the platform class Span, the computing unit can prune the platform class Span corresponding to the normal computing unit, retaining only key information.

[0110] In the embodiments of this application, key information includes, but is not limited to, at least one of the following: context information of the Span, time information of the Span, and identification information of the Span.

[0111] For example, before pruning, the computing unit (specifically, a distributed tracing tool for the computing unit) needs to determine whether the platform-type computing unit is a normal computing unit. This can be understood as follows: if it is a normal computing unit, pruning can be performed; if it is an abnormal computing unit, all Span Data of the Span corresponding to the abnormal computing unit needs to be reported to ensure the accuracy of Trace reconstruction, enabling users to accurately analyze the problems existing in the system. Here, an abnormal computing unit can be understood as a computing unit whose execution function encounters an exception; the specific cause of the exception is not limited.

[0112] For example, each computing unit can set filtering conditions (also called filtering rules). The filtering conditions of each computing unit can be the same or different, and this application does not limit this. The filtering conditions are used to indicate the normal range of the Span, which can also be understood as indicating whether the corresponding computing unit's work execution is normal, or as indicating whether the complete Span data needs to be reported.

[0113] Optionally, the filtering conditions may include the normal range corresponding to each parameter (or data). Specifically, the calculation unit (e.g., a distributed tracing tool) compares each piece of data (e.g., status code, execution time, etc.) of the acquired Span Data with the range corresponding to each piece of data set in the filtering conditions. If the data exceeds the range (including being less than or greater than), the calculation unit can be determined to be an abnormal calculation unit.

[0114] Figure 6 For an illustrative example of the differential tracking process, please refer to... Figure 6 Specifically, including but not limited to the following steps:

[0115] S601 determines whether a Span belongs to the platform class.

[0116] Specifically, after a Span's lifecycle ends, the Span can call the `end()` interface to be received by the distributed tracing tool in the computation unit. After obtaining the Span, the distributed tracing tool (specifically, the pruning module) can determine whether the Span is a platform-class Span, that is, whether the computation unit corresponding to the Span is a platform-class computation unit.

[0117] Specifically, the computing unit (which may be a distributed tracing tool deployed on the computing unit, as will not be repeated below) can obtain the type of computing unit monitored by the Span. If the computing unit is a platform-type computing unit, that is, the function executed by the computing unit is a platform function, then S602 is executed on the Span. That is, the Span can be pruned if it meets certain conditions.

[0118] In another example, if the computation unit is a user-class computation unit, that is, the function executed by the computation unit is a user function, then S606 is executed on the Span, that is, all Span Data of this type of Span needs to be retained and reported, and no pruning is required.

[0119] S602, obtain the filtering conditions for the corresponding computing unit.

[0120] For example, a distributed tracing tool can obtain the filtering conditions of the computational units corresponding to the Span to be pruned. Optionally, the filtering conditions corresponding to each computational unit can be the same or different, and this application does not limit this.

[0121] S603, based on filtering conditions, determines whether the calculation unit is functioning correctly.

[0122] Specifically, the distributed tracing tool determines whether a component is executing normally based on filtering conditions. In one example, if the Span Data is outside the normal range indicated by the filtering conditions, meaning the calculation unit is an abnormal calculation unit, then S606 is executed, which means that all Span Data needs to be reported.

[0123] In another example, if the Span Data is within the normal range indicated by the filter conditions, i.e., the computation unit is a normal computation unit, then S604 is executed to prune it.

[0124] S604 prunes the Span, preserving key information.

[0125] For example, distributed tools can prune Spans, that is, discard data in the Span Data other than key information, such as including but not limited to: "annotations", "tags", "attributes" etc., which are not limited in this application.

[0126] S606 serializes the Span.

[0127] For example, a distributed tracing tool can serialize a Span and send the serialized Span to the first node. The serialization method is described below and will not be repeated here.

[0128] In the embodiments of this application, each computing unit transmits the generated Span to the first node (which may be reported by the computing unit itself or reported by other computing units (i.e., asynchronous reporting)).

[0129] For example, after receiving the Spans from each computing unit, the first node places the received Spans in the reporting queue. Specifically, the first node receives all Spans from the Trace and performs serialization processing on the Spans. Serialization can be understood as the process of transforming a complex object into a format that is easy to store and transmit. In this embodiment, JSON (JavaScript Object Notation) mapping may be optionally used to serialize the Spans. Of course, other serialization methods may be used in other embodiments, and this application is not limited thereto.

[0130] For example, JSON is a lightweight data-interchange format commonly used to transmit and store data in a structured manner. JSON consists of key-value pairs, where each key corresponds to a single value. For instance, "Timestamp": "1718628999009971", where "Timestamp" is the key and "1718628999009971" is the corresponding value. This key-value pair represents a portion of the data in a Span Data object.

[0131] In one possible implementation, when each computing unit and the first node serialize the Span, the computing unit can compress the key-value pairs to reduce data overhead. For example, in "Timestamp": "1718628999009971", the key ("Timestamp") can be mapped to "t", and the value ("1718628999009971") can be compressed using base 36, i.e., "gx7c6j2msv". In this way, when the compressed and mapped Span is placed in the header of a call request (e.g., in an asynchronous scenario) or a call response (in a synchronous scenario), the number of bytes occupied can be reduced, and the bandwidth usage can be decreased, saving overhead.

[0132] The compression methods described in this application are merely illustrative examples and are not intended to limit the scope of the application. In this application, each computing unit negotiates a corresponding mapping method with the tracking device so that the tracking device can correctly identify the serialization result using the special mapping method of this application.

[0133] In one possible implementation, the distributed tool of the first node requests corresponding cache space for the reporting queue, and the first node can place the received Span in the cache space.

[0134] In another possible implementation, traditional distributed tracing technology uses context information to record the causal relationships between all spans generated by a single request. This context information is then used to reconstruct the tracing process as it propagates across the network and is received by the backend. Specifically, the context information of a span includes, but is not limited to, TraceID, Span ID, and its parent Span ID. The Trace ID determines whether these spans belong to the same request; the Span ID and parent Span ID determine the call relationship between two spans. However, this information is overly complex and can impose a significant load when embedding span serialization into the packet header in aggregated reporting methods. This application provides a context information framework, which may include, but is not limited to, height information. The height information indicates the call relationship of a span within a trace, or the call relationship of the component corresponding to the span within the workflow. This allows the tracing device to reconstruct a complete trace based on the height information in the context information of each span.

[0135] Optionally, in the embodiments of this application, the height information of each Span can be established based on the dependency relationship of the corresponding component in the workflow, or it can be understood as being established based on the depth of the corresponding component in the workflow. For example, Figure 7 As shown, component 1 calls component 2, and component 2 calls component 3; that is, component 3 depends on component 2, and component 2 depends on component 1. Accordingly, in this workflow, component 1 has a depth of 0, and its corresponding span's height can be set to 0; component 2 has a depth of 1, and its corresponding span's height can be set to 1; and component 3 has a depth of 2, and its corresponding span's height can be set to 2. The height information can be set according to actual needs; its purpose is to allow the span's height information to reflect the depth of the corresponding component in the workflow, i.e., the calling relationship.

[0136] In synchronous calls, only the height of the span in the call chain is needed to rebuild the trace. This can be understood as follows: in the reporting queue, the span with the smaller height (or the earlier the span is executed, the larger its height can be; this application does not limit this) will always finish executing first; that is, the computation unit corresponding to the span will always be executed first. For asynchronous cases, it may be optional to fall back to traditional context information settings, i.e., the context information of the span includes, but is not limited to: Trace ID, Span ID, and its parent Span ID.

[0137] In one example, if the distributed system adopts an asynchronous reporting strategy, the scheduling computing unit responds to the received request by reporting a response (also called a scheduling response, which is not limited in this application) to the user.

[0138] S402, if the reporting queue meets the reporting conditions, the first node transmits the reporting queue to the tracing device. The reporting conditions instruct the reporting queue to use the tracing link Trace as the reporting granularity, where Trace includes all spans generated by the same request in the workflow.

[0139] In this embodiment, after receiving the Span reported by the computing unit in the workflow, the first node caches the Span in storage. When the first node detects that the workflow has been completed, that is, all functions in the workflow have been executed, the first node places each cached Span in the reporting queue.

[0140] Optionally, after each Span is placed in the reporting queue, the first node can check whether all functions in the workflow have been executed completely. In one example, if not all functions have been executed, the workflow execution process continues, meaning it continues to retrieve the Spans reported by each computation unit in the workflow. In another example, if all functions have been executed, the reporting process is executed.

[0141] In this embodiment, the reporting queue is configured with reporting conditions, which can also be understood as reporting constraints. These constraints require that the spans in the reporting queue be complete spans within the trace. In other words, if a span in the reporting queue is incomplete, i.e., does not meet the constraint of reporting at the trace granularity, the first node will not report the reporting queue; for example, it can discard the reporting queue to avoid inaccurate trace reconstruction due to missing spans. Conversely, if a span in the reporting queue is complete, i.e., meets the constraint of reporting at the trace granularity, the first node can send the reporting queue to the tracking device.

[0142] Specifically, the first node can send a reporting message to the tracking device, which may include, but is not limited to, a reporting queue.

[0143] In summary, in this embodiment, by aggregating and reporting, the Spans generated by each computing unit in the workflow are aggregated into one computing unit (i.e., the first node) for reporting. This reduces network amplification, lowers resource overhead, and improves system throughput, while also preventing situations where excessive call depth prevents the inclusion of more Spans. For example, in some scenarios (such as microservice architectures), without the participation of a scheduling node, the scheduling of functions in the workflow might involve one node scheduling the next, and then the last scheduled node reporting Spans upwards level by level. Thus, the Spans sent upwards by the computing unit include its own Spans as well as those from other units. As the scheduling depth increases, the number of Spans that the computing unit needs to report will increase progressively, making it impossible for the message to carry excessively long Spans. Furthermore, this approach ensures the atomicity of Span reporting, preventing incomplete traces and improving the accuracy of trace reconstruction. Simultaneously, this application further reduces network amplification by using differential tracing, i.e., pruning Spans.

[0144] For example, when a tracing device receives a reporting queue, it can perform a trace reconstruction process based on the spans in the reporting queue. Specifically, after receiving the reporting queue, the tracing device can determine the dependencies between spans based on the context information of each span in the reporting queue, thereby reconstructing a complete trace.

[0145] Figure 8 For an illustrative diagram of the Trace reconstruction process, please refer to... Figure 8 Specifically, including but not limited to the following steps:

[0146] S801, receive and report queue.

[0147] For example, the first node can send a reporting message to the tracking device, which includes, but is not limited to, a reporting queue. The tracking device retrieves the reporting queue sent by the first node.

[0148] For example, each message in the embodiments of this application can be an HTTP message, and the message format can refer to existing technologies. This application does not limit it.

[0149] S802, determine if the reporting queue is empty.

[0150] For example, the tracking device iterates through the reporting queue and determines whether the reporting queue is empty. In one example, if the reporting queue is empty, meaning that all spans in the reporting queue have been reconstructed, the process ends. In another example, if the reporting queue is not empty, S803 is executed.

[0151] S803, retrieve the first Span from the reporting queue.

[0152] For example, the tracking device retrieves the Span currently at the head of the reporting queue, which is the first Span.

[0153] S804: Traverse the reporting queue and find the parent span of the first span based on the height information.

[0154] For example, the tracking device iterates through each Span in the reporting queue according to its order, from the first Span onwards. The tracking device can find the parent Span of the first Span based on the height information of each Span. For instance, if the height of the first Span is 5, then the Span with a height of 4 is the parent Span of the first Span; that is, the component corresponding to the first Span is called by the component corresponding to the Span with a height of 4.

[0155] S805 removes the first Span and its parent Span from the queue.

[0156] For example, the tracing device removes the first Span and its parent Span from the queue and persists the reconstruction relationship of the first Span and its parent Span to storage. The tracing device repeats step S802 until the reporting queue is empty to obtain a complete trace.

[0157] The following is combined with Figure 9 and Figure 9 The different scenarios for synchronous and asynchronous strategies are explained in detail.

[0158] Figure 9 For an illustrative example of the execution flow diagram of the computing unit, please refer to... Figure 9 This example uses the first node as the scheduling node for illustration, and includes, but is not limited to, the following steps:

[0159] S901, the scheduling node receives the user's workflow request.

[0160] For example, a scheduling node receives a workflow request. For instance, a user can use the user interface provided by the scheduling node to input scheduling instructions, and the scheduling node, in response to the received user instructions, retrieves the corresponding workflow request. The workflow request is used to instruct the invocation of a specified entry function.

[0161] S902, the scheduling node responds to the workflow request and begins executing the workflow.

[0162] For example, in response to a received workflow request, the scheduling node begins to execute the workflow, that is, each computing unit in the workflow begins to execute its corresponding function, or in other words, each computing unit in the workflow begins to run its corresponding function. Optionally, the scheduling node also runs the corresponding function and generates corresponding trace data (i.e., Span). In this embodiment, each computing unit may generate one or more Spans, which will not be repeated below.

[0163] S903, the scheduling node determines whether there are any unexecuted functions.

[0164] For example, each time the scheduling node receives the execution result and tracking data (i.e., Span) from a computing unit, it executes S903 to determine whether there are any unexecuted functions in the workflow.

[0165] In one example, if there are still unexecuted functions, then execution continues with S904.

[0166] In another example, if all functions in the workflow have been executed, then S907 is executed, which is the process of tracking data reporting.

[0167] Optionally, as mentioned above, a computing node may correspond to one or more spans, that is, a computing node may return one or more spans, which is not limited in this application.

[0168] S904, the scheduling function of the scheduling node is executed.

[0169] For example, if the scheduling node detects that the workflow still includes functions that have not been executed, it will continue to call the next function to execute according to the predetermined order of the workflow.

[0170] Specifically, such as Figure 10 As shown, each time a scheduling node calls a computing unit, it can send a call request to that computing unit to execute a specified function; this can also be understood as calling the corresponding function. The scheduling method can be found in [reference needed]. Figure 2a This will not be elaborated upon here.

[0171] S905, the scheduling node obtains execution results and tracking data.

[0172] For example, in response to a received call request, the computing unit invokes the Start() interface of the distributed tracing tool to create a Span for monitoring the execution status of the computing unit's work. The computing unit then begins executing the corresponding function. During the execution of the function, the Span continuously monitors the computing unit's work execution status.

[0173] For example, after the function execution is complete, the computation unit calls the End() interface of the distributed tracing tool to terminate the Span. The distributed tracing tool can then obtain the corresponding Span. For example, the distributed tracing tool can set its height information and perform differential tracing on the Span. The specific process can be found above and will not be repeated here.

[0174] For example, the computation unit (specifically, a distributed tracing tool) serializes the Span and places it in the header of the scheduling response message. Still referring to... Figure 10 The compute node sends a scheduling response to the scheduling node. The scheduling response includes, but is not limited to, the execution result and trace data (i.e., Span).

[0175] Figure 11 For an illustrative example of the asynchronous computing unit processing flow diagram, please refer to... Figure 11 Specifically, including but not limited to:

[0176] S1101, place the Span in the call request.

[0177] Figure 12 For an illustrative example of an asynchronous call flow, please refer to... Figure 12 If the computation unit is asynchronous, taking computation unit 1 and computation unit 2 as an example, computation unit 1 sends a call request to computation unit 2 to invoke computation unit 2. Computation unit 2 responds to the received call request by sending a call response to computation unit 1. Subsequently, computation unit 2 executes the corresponding function. In this example, since the Span has not yet finished monitoring computation unit 2 when computation unit 2 sends back the call response, in asynchronous scenarios, the distributed tracing system can include the Span in the call request. For example, computation unit 1 can send the Span to computation unit 2 in the call request. Computation unit 2, in response to the received call request, can obtain the Span transmitted by computation unit 1. Optionally, the Span transmitted by computation unit 1 may be its own Span, or it may include both its own Span and the Span received by computation unit 1 (i.e., the Span sent by at least one computation unit preceding computation unit 1 in the workflow).

[0178] Specifically, after obtaining the Span, the distributed tracing tool can optionally perform differential tracing processes on the Span, as detailed above, and will not be repeated here. The distributed tracing tool serializes the Span and places it in the header of the call request message. The serialization method can be the compression mapping method described in the embodiments of this application, or it can be a serialization method in the prior art; this application does not limit it.

[0179] S1102, send a call request to the next computing unit.

[0180] Still refer to Figure 12 For example, computation unit 2 can send a call request to the next computation unit (e.g., computation unit 3) to call the next computation unit to execute the corresponding function.

[0181] S1103, the next computing unit receives the call request and obtains the Span.

[0182] Still refer to Figure 12 For example, the next computing unit (e.g., computing unit 3) responds to the received call request, obtains the Span, and sends a call response to the previous computing unit (e.g., computing unit 2).

[0183] For example, computation unit 3 caches the acquired Spans (including the Spans of computation unit 1 and computation unit 2) in the cache space requested by the distributed tracing tool. Furthermore, computation unit 3 can execute the corresponding function. Optionally, in asynchronous scenarios, the computation unit can use the time between the Span's generation time and the time the call request is sent as the Span's latency, i.e., as the Span's time information, so that the tracing device can analyze the component's execution based on the Span's latency.

[0184] For example, if the computation unit (i.e., the currently being processed computation unit, i.e., computation unit 3) continues to call the next computation unit, and the next computation unit is also processed asynchronously, then the component will place its own generated Span and the cached Span (i.e., the Span received from the previous computation unit) in the call request and send them to the next computation unit. In other words, the Span received by the computation unit in the asynchronous scenario is a collection of Spans from all components in the workflow that precede that computation unit.

[0185] In one possible implementation, if all computational units in the scenario are asynchronous, then in this embodiment, the computational unit that aggregates and reports the Span may be the last computational unit in the workflow. That is, each computational unit in the workflow transmits its generated Span and cached Span downwards.

[0186] In another possible implementation, if the scenario includes synchronous computing units and asynchronous computing units, the synchronous computing units are still executed in the manner of a synchronous scenario, and the asynchronous computing units are executed in the manner of an asynchronous scenario.

[0187] For example, suppose computing units 1-3 in the system are asynchronous nodes, and computing units 4-6 are synchronous nodes. In this example, computing units 1-3 execute according to the asynchronous processing flow described above. Computing unit 3 will obtain the Spans generated by computing units 1 and 2. After computing unit 3 completes its execution, it sends its generated Span, the Spans generated by computing units 1 and 2, and the execution result of computing unit 3 to the scheduling node. The scheduling node calls computing unit 4, sends the execution result of computing unit 3 to computing unit 4, and after computing unit 4 completes its execution, it sends a response back to the scheduling node. The response includes, but is not limited to, the execution result and the generated Span. The process for computing units 5 and 6 is the same, and will not be repeated here. The scheduling node places the obtained Spans in the reporting queue for reporting. To illustrate further, suppose computing units 1-3 are synchronous nodes, and computing units 4-6 are asynchronous nodes. The scheduling node can obtain the Spans of computing units 1-3. The scheduling node calls computing unit 4, computing unit 4 sends a response back to the scheduling node, and executes the corresponding function. After execution, computation unit 4 sends a call request to computation unit 5, the request including but not limited to: the execution result and the generated span. Computation unit 5, similar to computation unit 4, sends a request to computation unit 6 after execution, the request including but not limited to the execution result and span (including the spans of computation unit 5 and computation unit 4). In this scenario, optionally, computation unit 6 can send a message to the calling node, the message including but not limited to the spans of computation units 4 to 6. Optionally, when the scheduling node sends a call request to scheduling node 4, the request may also include the spans of computation units 1 to 3. Correspondingly, the spans included in the request sent by scheduling unit 4 are the spans generated by computation units 1 to 4. The spans included in the request sent by computation unit 5 to computation unit 6 are the spans of computation units 1 to 5, and computation unit 6 can report spans, including the spans it generates and the spans generated by computation units 1 to 5. Optionally, if the last computation unit in the workflow is an asynchronously executed node, then this computation unit can also act as an aggregation node (e.g., the first node described in this embodiment) to transmit the reporting queue to the tracking device. Optionally, the technical solutions in this application embodiment can be applied not only to serverless architectures but also to other architectures, such as microservice architectures. In a microservice architecture, the calling method of computing units may be that one computing unit (i.e., the parent computing unit) calls the next computing unit (i.e., the child computing unit), and after the computing unit completes its execution, it returns the execution result and Span to the parent computing unit that called it. For example, the dependency relationship between computing units 1 to 3 in the workflow is that computing unit 1 calls computing unit 2, and computing unit 2 calls computing unit 3.The scheduling node sends a call request to computing unit 1. Computing unit 1 executes the function, and Span1 monitors the execution status of computing unit 1. Computing unit 1 sends a call request to computing unit 2, including the execution result. Computing unit 2 executes the corresponding function based on the execution result of computing unit 1, and Span2 monitors the execution status of computing unit 2. Computing unit 2 sends a call request to computing unit 3, including the execution result of computing unit 2. Computing unit 3 executes the corresponding function based on the execution result of computing unit 2, generating Span3, which monitors the execution status of computing unit 3. Computing unit 3 sends a call response to computing unit 2, including Span3. Computing unit 2 completes execution and generates Span2. Computing unit 2 sends a call response to computing unit 1, including Span3 and Span2. Computing unit 1 completes execution and generates Span1. Computing unit 1 sends a call response to the scheduling node, including Span1, Span2, and Span3. The scheduling node reports the acquired Spans (including Span1 to Span3, and may also include its own generated Span0) to the tracing device. Optionally, in a microservice architecture, the aggregation node can also be one of the computing units (e.g., the first node described in this embodiment). Computing units preceding it can transmit Spans to the first node via a call request, and computing nodes executing after the first computing node can transmit Spans to the first computing node via a response. For example, computing node 1 sends a call request to computing node 2, and the request may include the Span of computing node 1. Computing node 2, as the aggregation node, caches Span1. Computing node 2 calls computing node 3, and after computing node 3 completes its execution, it sends a call response back to computing node 2, which includes Span3. Computing node 2 generates Span2 and reports Span2, along with the cached Span1 and Span3, to the tracing device.

[0188] Figure 13 For an illustrative flowchart of the workflow tracing method, please refer to... Figure 13 Specifically, including but not limited to:

[0189] The scheduling and computing unit receives user requests. These requests instruct the execution of functions within a workflow, assuming the workflow includes two functions: function 1 and function 2. Of course, function 1 and function 2 combined can also be considered a single function; this application does not impose such a limitation. Furthermore, Figure 13 The functions, their component counts, and calling relationships shown are merely illustrative examples and are not intended to limit the scope of this application.

[0190] 1. The scheduling and computing unit responds to the user request and begins to execute the workflow.

[0191] Specifically, after the scheduling and computing unit receives a user request, the distributed tracing tool within the unit generates a Span1, for example, by calling the Start() interface of the distributed tracing tool to start the Span. The Span1 then begins monitoring the execution status of the scheduling nodes.

[0192] For example, the scheduling node searches for the computation unit corresponding to function 1, such as computation unit 1. During this process, Span1 continuously monitors the execution status of the scheduling node.

[0193] 2. The scheduling function 1 of the scheduling node is executed.

[0194] The scheduling node determines whether there are any unexecuted functions. In this example, the scheduling node detects that functions 1 and 2 have not been executed. Following the workflow's scheduling order, the scheduling node schedules function 1 for execution first.

[0195] Specifically, after the scheduling node finds the computing unit 1 corresponding to function 1, the scheduling node sends a call request 1 to computing unit 1 to request that computing unit 1 execute function 1.

[0196] Computation unit 1 creates a Span. Specifically, in response to call request 1, computation unit 1 calls the Start() interface to start the Span. Span2 then begins monitoring the execution status of computation unit 1.

[0197] Calculation unit 1 begins executing function 1. During execution, Span2 continuously monitors the execution status of calculation unit 1.

[0198] Upon completion of computation unit 1, it sends the execution result and tracing data (i.e., Span 2) to the scheduling node. Specifically, upon completion of computation unit 1, it calls the End() interface to end Span tracing. The distributed tracing tool obtains the Span. The distributed tracing tool also obtains the type of computation unit 1.

[0199] In one example, if computation unit 1 is a user-class computation unit, the distributed tracing tool will serialize Span2 and place it in the header of the scheduling response 1 message.

[0200] In another example, if computation unit 1 is a platform-type computation unit, the distributed tracing tool obtains the filtering conditions corresponding to computation unit 1 and determines whether pruning is needed based on the Span Data of Span2. If Span2 meets the filtering conditions, i.e., all parameters are within the normal range specified by the filtering conditions, it is pruned, retaining only key data. Key data includes, but is not limited to: the context of Span2, the time information of Span2, and the identification information of Span2. The distributed tracing tool serializes the pruned Span2 and places it in the response message header. If Span2 does not meet the filtering conditions, i.e., any parameter exceeds the normal range specified by the filtering conditions, the distributed tracing tool serializes Span2 and places it in the response message header.

[0201] Optionally, the context information of Span2 may include height information. For example, the height information of Span2 is 1. The setting of height information can be referred to the above, and will not be repeated here.

[0202] Alternatively, the distributed tracing tool can cache Span2 in the storage of computing unit 1.

[0203] For example, computing unit 2 sends scheduling response 1 to scheduling node, which includes, but is not limited to, execution results and trace data (i.e., Span 2).

[0204] Still refer to Figure 13 The scheduling node receives scheduling response 1. Specifically, the scheduling node receives scheduling response 1 and obtains the execution result and tracing data (Span2). The distributed tracing tool of the scheduling node caches Span2 in the allocated memory.

[0205] 3. The scheduling function 2 of the scheduling node is executed.

[0206] The scheduling node determines whether there are any unexecuted functions. In this example, the scheduling node detected that function 2 has not been executed.

[0207] The scheduling node searches for the computational unit corresponding to function 2, for example, computational unit 2. During the execution of the scheduling node, Span1 continues to monitor the execution status of the scheduling node.

[0208] After the scheduling node locates the computation unit 2 corresponding to function 2, it sends a call request 2 to computation unit 2, requesting that computation unit 2 execute function 2. The call request includes, but is not limited to, the execution result of computation unit 1, which serves as the input to function 2.

[0209] Computation unit 2 creates a Span. Specifically, in response to call request 1, computation unit 2 calls the Start() interface to start the Span. Span 3 then begins monitoring the execution status of computation unit 2.

[0210] Calculation unit 2 begins executing function 2. The result of function 1 from calculation unit 1 is used as the input to function 2. During execution, Span 3 continuously monitors the execution status of calculation unit 2.

[0211] Computation unit 2 finishes execution and sends the execution result and tracing data (i.e., Span 3) to the scheduling node. Specifically, upon completion of computation unit 2, the End() interface is called to end Span tracing. The distributed tracing tool obtains Span 3. The distributed tracing tool also determines the type of computation unit 2.

[0212] In one example, if computation unit 2 is a component of user function type, the distributed tracing tool will serialize Span3 and place it in the header of response 2.

[0213] In another example, if computation unit 2 is a platform-type component, the distributed tracing tool obtains the filtering conditions corresponding to computation unit 2 and determines whether pruning is needed based on the Span Data of Span3. If Span3 meets the filtering conditions, i.e., all parameters are within the normal range specified by the filtering conditions, it is pruned, retaining only key data. Key data includes, but is not limited to: the context of Span3, the time information of Span3, and the identification information of Span3. The distributed tracing tool serializes the pruned Span3 and places it in the response message header. If Span3 does not meet the filtering conditions, i.e., any parameter exceeds the normal range specified by the filtering conditions, the distributed tracing tool serializes the Span3 and places it in the response message header.

[0214] Optionally, the context information of Span3 may include height information. For example, the height information of Span3 is 2. The setting of height information can be referred to the above, and will not be repeated here.

[0215] Alternatively, the distributed tracing tool can cache Span3 in the storage of computing unit 2.

[0216] For example, computing unit 3 sends scheduling response 2 to scheduling node, which includes, but is not limited to, execution results and tracking data (i.e., Span 3).

[0217] 4. The scheduling node reports tracking data.

[0218] Still refer to Figure 13The scheduling node receives scheduling response 2. Specifically, the scheduling node receives the response and obtains the execution result and tracing data (Span2). The distributed tracing tool of the scheduling node caches Span3 in the allocated memory.

[0219] The scheduling node determines if there are any unexecuted functions. In this example, the scheduling node detects that all functions have been executed. The scheduling node then begins the reporting process.

[0220] Specifically, the scheduling node calls the Start() interface to end Span tracing. The distributed tracing tool then obtains Span1.

[0221] The distributed tracing tool retrieves the cached Span2 and Span3. The tool then serializes Span1, Span2, and Span3; the specific method is described above and will not be repeated here.

[0222] Distributed tracing tools can place Spans in the reporting queue according to the acquisition order, such as Span2, Span3, and Span1. Optionally, the distributed tracing tool can also place its own generated Span1 at the beginning of the queue, with other Spans arranged in the acquisition order. Of course, they can also be arranged randomly; this application does not impose any restrictions on the order of Spans in the reporting queue.

[0223] The scheduling node sends a tracking report message to the tracking device, which includes the reporting queue.

[0224] 5. Reconstruct the trace using the tracking device.

[0225] Specifically, in response to the received tracking report message, the tracking device obtains the reporting queue and, following the Trace reconstruction process described above, rearranges the Spans based on their height information and obtains the complete Trace.

[0226] The above mainly describes the solution provided by the embodiments of this application from the perspective of interaction between various network elements. It is understood that, in order to achieve the above functions, the workflow tracing device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0227] This application embodiment can divide the workflow tracing device into functional modules based on the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0228] When each function is divided into its own modules, the remaining modules are defined according to their respective functions. Figure 14 A possible structural schematic diagram of the workflow tracing device 1400 involved in the above embodiments is shown, such as... Figure 14 As shown, the workflow tracing device may include, but is not limited to, an organization module 1401 and a reporting module 1402. The organization module 1401 is used to acquire at least one span (Span) of each computational unit in the workflow and place the acquired Span in a reporting queue. The Span is used to track the execution status of the corresponding computational unit when it executes its corresponding function. The reporting module 1402 is used to transmit the reporting queue to the tracing device if the reporting queue meets the reporting conditions; the reporting conditions instruct the reporting queue to report at the tracing link Trace granularity, where Trace includes all Spans generated by the same request in the workflow.

[0229] In one possible implementation, the reporting module 1402 is also used to: discard all Spans in the reporting queue if the reporting queue does not meet the reporting conditions.

[0230] In one possible implementation, the data of each Span includes key information, which includes at least one of the following: the height information of the Span, the time information of the Span, and the identification information of the Span; wherein, the height information is used to indicate the calling relationship of the calculation unit corresponding to the Span in the workflow.

[0231] In one possible implementation, at least one Span is sent by the corresponding computing unit after pruning based on pruning conditions, which are used to indicate whether the execution of the corresponding computing unit has encountered any abnormalities.

[0232] In one possible implementation, information other than key information in a Span that meets the pruning conditions is discarded; the key information includes at least one of the following: the height information of the Span, the time information of the Span, and the identification information of the Span.

[0233] In one possible implementation, the first node is a scheduling node, and the device further includes a calling module 1403, which is used to send a calling request information to a single computing unit, the calling request information being used to instruct the single computing unit to execute a corresponding function; and to receive a calling response information sent by the single computing unit, the calling response information including the execution result of the single computing unit and at least one Span.

[0234] In one possible implementation, the first node is one of the computational units in the workflow, wherein the computational unit in the workflow sends its own generated Span, or its own generated Span and the Span received by the computational unit, to the first node.

[0235] In another example, Figure 15 A schematic block diagram of a workflow tracing device 1500 according to an embodiment of this application is shown. The workflow tracing device may include a processor 1501 and a transceiver / transceiver pin 1502, and optionally, a memory 1503. The processor 1501 can be used to execute the steps performed by the distributed tracing tool or the first node in the methods of the foregoing embodiments, and control the receive pin to receive signals, and control the transmit pin to transmit signals.

[0236] The various components of the workflow tracing device 1500 are coupled together via a bus 1504, which includes a data bus, a power bus, a control bus, and a status signal bus. However, for clarity, all buses are labeled as bus system 1504 in the figure.

[0237] Optionally, the memory 1503 can be used for storage instructions in the foregoing method embodiments.

[0238] It should be understood that the workflow tracing device 1500 according to the embodiments of this application may correspond to the distributed tracing tool or the first node in the methods of the foregoing embodiments, and the above and other management operations and / or functions of each element in the workflow tracing device 1500 are respectively for implementing the corresponding steps of the foregoing methods, which will not be described in detail here for the sake of brevity.

[0239] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0240] Based on the same technical concept, embodiments of this application also provide a computer-readable storage medium storing a computer program containing at least one piece of code that can be executed by a workflow tracing device to control the workflow tracing device to implement the above-described method embodiments.

[0241] Based on the same technical concept, this application also provides a computer program, which, when executed by a workflow tracing device, is used to implement the above-described method embodiments.

[0242] The program may be stored, in whole or in part, on a storage medium packaged with the processor, or in part or in whole on a memory not packaged with the processor.

[0243] Based on the same technical concept, this application also provides a processor for implementing the above-described method embodiments. The processor can be a chip.

[0244] The steps of the methods or algorithms described in conjunction with the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Additionally, the ASIC can reside in a network device. Alternatively, the processor and storage medium can exist as discrete components in the network device.

[0245] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0246] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0247] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0248] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0249] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0250] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A workflow tracing method, characterized in that, Applied to the first node, the method includes: Obtain at least one span for each computational unit in the workflow and place the obtained span in a reporting queue; wherein, the span is used to track the work execution status when the corresponding computational unit executes the corresponding function; If the reporting queue meets the reporting conditions, the reporting queue is transmitted to the tracking device; wherein, the reporting conditions are used to instruct the reporting queue to report at the tracking link Trace granularity, and the Trace includes all Spans generated by the same request in the workflow.

2. The method according to claim 1, characterized in that, The method further includes: If the reporting queue does not meet the reporting conditions, all Spans in the reporting queue are discarded.

3. The method according to claim 1, characterized in that, The data for each Span includes key information, which includes at least one of the following: Span height information, Span time information, and Span identification information; The height information is used to indicate the calling relationship of the computing unit corresponding to the Span in the workflow.

4. The method according to claim 1, characterized in that, The at least one Span is sent by the corresponding computing unit after pruning based on pruning conditions, which are used to indicate whether there is an abnormality in the work execution of the corresponding computing unit.

5. The method according to claim 4, characterized in that, in, Information other than key information in a Span that meets the pruning conditions is discarded; the key information includes at least one of the following: Span height information, Span time information, and Span identification information.

6. The method according to claim 1, characterized in that, The first node is a scheduling node, and before obtaining at least one Span for each computational unit of the workflow, the method includes: Send a call request message to a single computing unit, the call request message being used to instruct the single computing unit to execute a corresponding function; Receive the call response information sent by the single computing unit, the call response information including the execution result of the single computing unit and at least one Span.

7. The method according to claim 1, characterized in that, The first node is one of the computing units in the workflow, wherein the computing unit in the workflow sends its own generated Span, or its own generated Span and the Span received by the computing unit, to the first node.

8. A workflow tracking device, characterized in that, Applied to the first node, including: An organization module is used to obtain at least one span for each computational unit in the workflow and place the obtained span in a reporting queue; wherein, the span is used to track the work execution status when the corresponding computational unit executes the corresponding function; The reporting module is used to transmit the reporting queue to the tracking device if the reporting queue meets the reporting conditions; wherein the reporting conditions are used to instruct the reporting queue to report at the tracking link Trace granularity, and the Trace includes all Spans generated by the same request in the workflow.

9. The apparatus according to claim 8, characterized in that, The reporting module is also used for: If the reporting queue does not meet the reporting conditions, all Spans in the reporting queue are discarded.

10. The apparatus according to claim 8, characterized in that, The data for each Span includes key information, which includes at least one of the following: Span height information, Span time information, and Span identification information; The height information is used to indicate the calling relationship of the computing unit corresponding to the Span in the workflow.

11. The apparatus according to claim 8, characterized in that, The at least one Span is sent by the corresponding computing unit after pruning based on pruning conditions, which are used to indicate whether there is an abnormality in the work execution of the corresponding computing unit.

12. The apparatus according to claim 11, characterized in that, in, Information other than key information in a Span that meets the pruning conditions is discarded; the key information includes at least one of the following: Span height information, Span time information, and Span identification information.

13. The apparatus according to claim 8, characterized in that, The first node is a scheduling node, and the device further includes a calling module for: Send a call request message to a single computing unit, the call request message being used to instruct the single computing unit to execute a corresponding function; Receive the call response information sent by the single computing unit, the call response information including the execution result of the single computing unit and at least one Span.

14. The apparatus according to claim 8, characterized in that, The first node is one of the computing units in the workflow, wherein the computing unit in the workflow sends its own generated Span, or its own generated Span and the Span received by the computing unit, to the first node.

15. A computer storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-7.

16. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-7.

17. A chip, characterized in that, The device includes one or more interface circuits and one or more processors; the interface circuits are configured to receive signals from the memory of the electronic device and send the signals to the processors, the signals including computer instructions stored in the memory; when the processor executes the computer instructions, the electronic device performs the method according to any one of claims 1-7.

Images