Network jitter diagnosis method and device, equipment and medium

Abstract

The invention relates to the technical field of network operation and maintenance, and discloses a network jitter diagnosis method and device, equipment and a medium. The method comprises the following steps: when a data packet is confirmed to be delivered, calculating network jitter data; embedding the network jitter data into the service calling link data to obtain embedded link data; and carrying out jitter root cause analysis on the embedded link data to obtain a network jitter diagnosis result. According to the embodiment of the invention, the network jitter can be accurately associated with the affected user, and the influence of the network jitter on the service is clear.

Description

Network jitter diagnosis methods, devices, equipment and media Technical Field

[0001] This application relates to the field of network operation and maintenance technology, and in particular to a method, apparatus, device and medium for diagnosing network jitter. Background Technology

[0002] Network jitter is an important indicator of network quality, and its impact cannot be ignored.

[0003] Network jitter refers to the amount or fluctuation in the transmission time of network data packets. Excessive jitter can lead to problems such as degraded voice quality, dropped frames in games, and video stuttering, which seriously affect the user experience.

[0004] However, in related technologies, the detection data obtained by network jitter diagnosis methods are often completely disconnected from business transactions, making it difficult to accurately associate network jitter with affected users, and failing to clearly define the impact of network jitter on business, resulting in business losses that are difficult to measure. Summary of the Invention

[0005] The purpose of this application is to provide a network jitter diagnosis method, apparatus, device, and medium that can accurately associate network jitter with affected users and clarify the impact of network jitter on services.

[0006] This application provides a network jitter diagnosis method, including: calculating network jitter data when a data packet is confirmed to have been delivered; embedding the network jitter data into service call link data to obtain embedded link data; and performing jitter root cause analysis on the embedded link data to obtain a network jitter diagnosis result.

[0007] In some embodiments, calculating network jitter data includes: acquiring the sending time information and arrival time information of the data packet; calculating the corresponding RTT measurement value based on the sending time information and the arrival time information; and calculating the absolute difference between consecutive RTT measurement values ​​to obtain the network jitter data.

[0008] In some embodiments, embedding the network jitter data into the service call link data includes: encapsulating the network jitter data into OTel data format to obtain encapsulated network jitter data; and embedding the encapsulated network jitter data as metric data or as span attribute data into the service call link data to obtain the embedded link data.

[0009] In some embodiments, the jitter root cause analysis of the embedded link data includes: summarizing each of the embedded link data within a preset time period; performing jitter feature relationship analysis on the embedded link data to obtain jitter relationship features that characterize the relationship between network jitter, service transactions, and terminals during a single data transmission; performing jitter feature correlation analysis on each of the jitter relationship features to obtain jitter correlation features that characterize the correlation between the topologies of each of the jitter relationship features; and generating the network jitter diagnosis result based on the jitter correlation features.

[0010] In some embodiments, the jitter feature relationship analysis of the embedded link data includes: extracting network jitter data, transaction data, and terminal identity data from the embedded link data; and associating the extracted network jitter data, transaction data, and terminal identity data to obtain the jitter association features.

[0011] In some embodiments, the step of performing jitter feature association analysis on each of the jitter relationship features includes: forming a business transaction group based on the transaction data in each of the jitter relationship features; determining the initial business transaction in the business transaction group based on the time information of the transaction data; and associating the transaction data, network jitter data, and terminal identity data corresponding to the initial business transaction to obtain the jitter association feature.

[0012] In some embodiments, generating the network jitter diagnosis result based on the jitter association features includes: determining the abnormal terminal causing the network jitter based on the jitter association features; displaying a three-dimensional heatmap describing the link relationship between network jitter, service transactions, and the terminal; and marking the abnormal terminal and the service call link containing the abnormal terminal in the three-dimensional heatmap as the network jitter diagnosis result.

[0013] This application embodiment also provides a network jitter diagnostic device, comprising: a first module for calculating network jitter data when a data packet is confirmed to have been delivered; a second module for embedding the network jitter data into service call link data to obtain embedded link data; and a third module for performing jitter root cause analysis on the embedded link data to obtain network jitter diagnostic results.

[0014] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described network jitter diagnosis method.

[0015] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described network jitter diagnosis method.

[0016] The beneficial effects of this application are as follows: By calculating network jitter data upon data packet delivery confirmation, embedding the calculated network jitter data into the business call chain data, and performing root cause analysis, corresponding network jitter diagnostic results are obtained. Therefore, by effectively embedding the calculated network jitter data with the business call chain data, a deep integration of network performance indicators and business context is achieved. This makes network jitter data no longer an isolated number, but closely related to specific business operations, service call paths, and end users. It allows for precise association between network jitter and affected users, clearly identifying the impact of network jitter on business operations. Attached Figure Description

[0017] Figure 1 is a flowchart of the network jitter diagnosis method provided in an embodiment of this application.

[0018] Figure 2 is a flowchart of a specific method for calculating network jitter data provided in an embodiment of this application.

[0019] Figure 3 is a flowchart of a specific method for embedding network jitter data into service call link data according to an embodiment of this application.

[0020] Figure 4 is a flowchart of a specific method for jitter root cause analysis of embedded link data provided in an embodiment of this application.

[0021] Figure 5 is a schematic diagram of the network jitter diagnostic device provided in an embodiment of this application.

[0022] Figure 6 is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0024] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and drawings are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0025] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0026] The network jitter diagnosis method provided in this application can be executed by a computer device, which can be a terminal or a server. The terminal includes, but is not limited to, mobile phones, computers, smart home appliances, vehicle terminals, and aircraft. The server can be a standalone physical server, a server cluster consisting of multiple physical servers, a distributed system, or a cloud server.

[0027] Furthermore, the information, data, and signals involved in the embodiments of this application are all authorized by the relevant parties or fully authorized by all parties, and the collection, use, and processing of the relevant data comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0028] In traditional network jitter diagnostic technologies, network jitter data and service call chain data are independent of each other. This makes it impossible to establish a correlation between network jitter and affected service transactions and end users, making it difficult to accurately measure service losses. The isolation of network jitter data prevents the system from mapping packet transmission time fluctuations to specific service sessions. Furthermore, the deterioration trend of service performance indicators cannot be effectively tracked, resulting in a lack of business context support in the fault diagnosis process. For example, in a distributed video conferencing system, when network jitter occurs, existing diagnostic methods can only obtain jitter measurements at the network layer, failing to bind this jitter data to specific video session transactions and participating terminals. The packet transmission time fluctuations are disconnected from user sessions, making it impossible for the system to identify the actual impact of jitter on the service experience of specific terminals. Furthermore, the initial session in the service transaction group cannot be accurately located, resulting in a lack of correlation between terminal identity data and network jitter data, making it difficult to attribute the cause of service interruption.

[0029] If the above problems are not resolved, service interruptions caused by network jitter cannot be effectively attributed, the continuous deterioration trend of service performance indicators is difficult to analyze systematically, which leads to a decline in service quality and a decrease in troubleshooting efficiency. In particular, the lack of a business loss quantification mechanism will result in insufficient basis for operation and maintenance decisions, and thus the negative effects on user experience cannot be corrected in a timely manner.

[0030] Based on this, embodiments of this application provide a network jitter diagnosis method, apparatus, device, and medium. By calculating network jitter data and embedding service call link data for root cause analysis, the association between network jitter and service context is realized, enabling precise association between network jitter and affected users, and clarifying the impact of network jitter on services.

[0031] Referring to Figure 1, in one embodiment, a network jitter diagnosis method is provided. The execution subject of the method can be a terminal or a server, including but not limited to steps S101 to S103.

[0032] Step S101: Calculate network jitter data when the data packet is confirmed to have been delivered.

[0033] A data packet is the basic unit of data transmitted in a network, typically containing a payload and control information. During network communication, data is segmented into multiple data packets for transmission and then reassembled at the receiving end.

[0034] Network jitter data refers to data that measures the variation or fluctuation in the transmission time of network data packets. This data reflects the instability of data packet transmission delay in the network and is an indicator for evaluating network service quality.

[0035] Network jitter data can be calculated in several ways upon confirmation of data packet delivery. For example, one method is to record the sending timestamp of a data packet when it is sent and the receiving timestamp when it is confirmed by the receiver. By comparing these timestamps, the transmission delay of each data packet can be calculated. Subsequently, the difference between the average and maximum transmission delays of all data packets over a period of time can be used as the network jitter data for that period. Another method is to periodically send probe packets to the target address and record the round-trip time of each probe packet. Then, the standard deviation of the round-trip time sequence of multiple consecutive probe packets can be calculated to characterize the volatility of network transmission; this standard deviation is the network jitter data. Alternatively, changes in the queue depth of network device interfaces can be monitored; when the queue depth fluctuates drastically within a short period, the amplitude of this fluctuation can be used as network jitter data.

[0036] Step S102: Embed network jitter data into service call link data to obtain embedded link data.

[0037] Business call chain data refers to data that records the various services and components a complete business transaction passes through from its initiation to its completion, as well as the call relationships and timing information between them. This data is usually presented in the form of distributed tracing and is used to monitor and diagnose performance problems in complex business systems.

[0038] Embedded link data refers to data formed by integrating network jitter data with business call link data. This data links network-level performance indicators with application-level business processes, providing a unified perspective for comprehensively analyzing the impact of network problems on business operations.

[0039] Embedding network jitter data into business call chain data can be achieved by appending the calculated network jitter data to the business call chain data in various forms. For example, one approach is to reserve a custom field in the business call chain data and directly write the network jitter data into this field. When the business call chain data is collected, the network jitter data in this custom field is also transmitted and stored. Another approach is to generate a unique transaction identifier for each business transaction and associate this transaction identifier with the corresponding network jitter data, storing it in a separate database or log file. When analysis is needed, the network jitter data can be matched with the business call chain data using this transaction identifier. Alternatively, the network jitter data can be encapsulated into a separate log event, ensuring that this log event contains the same associated identifier as the business call chain data, such as a request ID or session ID, for subsequent correlation queries.

[0040] Step S103: Perform jitter root cause analysis on the embedded link data to obtain network jitter diagnosis results.

[0041] Jitter root cause analysis refers to the process of identifying the root causes of network jitter through in-depth mining and correlation analysis of embedded link data. This analysis aims to pinpoint specific network devices, service nodes, or service operations, thereby effectively resolving network performance issues.

[0042] Network jitter diagnostic results refer to the conclusions drawn from root cause analysis of network jitter issues, including their causes, scope of impact, and possible solutions. These results provide network operations personnel with a basis for decision-making, enabling them to take targeted optimization measures.

[0043] There are several ways to perform jitter root cause analysis on the embedded link data. For example, one approach is to perform simple statistical analysis on the collected embedded link data, such as calculating the average network jitter value for each service node or terminal over a period of time. When the average network jitter value of a service node or terminal exceeds a preset threshold, it is marked as a potential jitter source, and a corresponding diagnostic report is generated. Another approach is to group service call links with similar jitter characteristics based on the timestamp information in the embedded link data. Then, these service call links in the groups are manually examined to identify common abnormal patterns or shared infrastructure components, thereby inferring the jitter root cause. Alternatively, a simple rule engine can be built, pre-setting some mapping relationships between jitter patterns and potential root causes. When a jitter pattern in the embedded link data matches a preset rule, the corresponding root cause diagnosis result is triggered.

[0044] The following example provides a more detailed explanation of the above technical solution: Suppose user A purchases goods through an online shopping platform at location A. When submitting the order, user A finds the page response slow and laggy. To diagnose this problem, the method provided in this embodiment is activated.

[0045] First, when data packets are transmitted between user A's device and the shopping platform server and delivery is confirmed, the executing entity calculates the corresponding network jitter data. For example, the executing entity can continuously monitor the data packet transmission latency between user A's device and the platform server. Suppose that within a short period after user A submits an order, the executing entity detects large fluctuations in the transmission latency of several consecutive data packets; for example, the first data packet has a latency of 50 milliseconds, the second 120 milliseconds, and the third 60 milliseconds. The executing entity will calculate network jitter data based on these latency values, for example, by calculating the variance or maximum difference of these latency values ​​to quantify the degree of jitter.

[0046] Subsequently, the network jitter data is embedded into the business call chain data. When the business transaction of user A submitting an order flows within the shopping platform, a detailed business call chain data is generated, recording the call order, time consumption, and interrelationships of a series of microservices from user interface services to order processing services, inventory services, payment services, etc. In this embodiment, the calculated network jitter data (e.g., the aforementioned latency variance value) is appended to the chain data related to the specific business transaction of user A submitting an order. For example, a custom tag with the value of the network jitter data can be added to a key span of this business transaction. Thus, the network jitter information is closely integrated with the specific business operation and the service call path involved.

[0047] Finally, a jitter root cause analysis was performed on the embedded link data to obtain the corresponding network jitter diagnosis results. The execution entity collected embedded link data of user A's order submission, which included network jitter information. The analysis module processed this data. For example, the execution entity could identify that in user A's order submission link, the network jitter data was significantly higher than other links when calling the payment service. Through further analysis, the execution entity found that all business call links accessing the payment service from user A's region within a specific time period exhibited high network jitter. The execution entity could further correlate the network paths and infrastructure traversed by these links, ultimately locating a network router at location B with an abnormal configuration, causing network jitter when users in that region accessed the payment service. Thus, the execution entity generated a diagnosis result, clearly stating that "the lag problem encountered by user A when submitting an order was caused by an abnormal network router at location B, resulting in excessive network jitter when accessing the payment service." This diagnosis result not only pointed out the network jitter but also associated it with the specific business transaction (order submission), the affected user (user A), and the specific root cause (network router at location B), providing a clear fault location.

[0048] Based on the above examples, the technical solution of this embodiment demonstrates significant technical contributions. In existing technologies, network jitter diagnosis methods often only provide isolated network jitter data, such as network latency and packet loss rate. This data is disconnected from specific business transactions and user experience. For example, in the above example, if only network router jitter is detected at location B, but it cannot be directly correlated with the lag issue when user A submits an order, it is difficult to determine the extent of the jitter's impact on the business, and it is also impossible to accurately locate the affected user.

[0049] This embodiment achieves deep integration of network performance metrics and business context by effectively embedding calculated network jitter data with business call chain data. This innovative combination transforms jitter data from isolated numbers into something closely linked to specific business operations, service call paths, and end users. For example, in the example above, network jitter data is directly appended to the business call chain of user A submitting an order, enabling subsequent analysis to directly identify which business link (such as a payment service call) was affected by network jitter.

[0050] Furthermore, by performing root cause analysis on the embedded link data, this embodiment can provide accurate network jitter diagnostic results. Unlike existing technologies that may only provide a vague conclusion of "network jitter exists," this embodiment can clearly point out that "the lag problem encountered by user A when submitting an order is caused by an abnormal network router at location B, resulting in excessive network jitter when accessing the payment service." This diagnostic result not only locates the specific network location where the jitter occurs but also correlates it with the affected business transactions and user experience, enabling maintenance personnel to quickly understand the scope and priority of the problem and take targeted measures to repair it. This solution effectively solves the problems of network jitter diagnostic data being disconnected from business transactions, difficulty in accurately correlating user and business impacts, and difficulty in measuring business losses in existing technologies, significantly improving the efficiency and accuracy of network fault diagnosis.

[0051] Referring to Figure 2, in one embodiment, the specific method for calculating network jitter data includes, but is not limited to, steps S201 to S203.

[0052] Step S201: Obtain the data packet's sending time information and delivery time information.

[0053] Step S202: Calculate the corresponding RTT measurement value based on the transmission time information and the delivery time information.

[0054] Step S203: Calculate the absolute difference between consecutive RTT measurements to obtain network jitter data.

[0055] Sending time information refers to the precise time when a data packet is sent from the source device, while arriving time information refers to the precise time when the data packet is received by the destination device. These timestamps are the fundamental data for measuring data packet transmission delay. This information can be implemented by embedding a timestamp field in the protocol header or payload of the data packet. For example, at the sending end, when a data packet is ready to be sent, the current system time is obtained and written to the data packet; at the receiving end, when the data packet is successfully received, the current system time is read. Alternatively, network devices can timestamp data packets as they pass through. For example, network devices supporting PTP (Precision Time Protocol) or NTP (Network Time Protocol) can add high-precision timestamps when data packets arrive and depart, and record or transmit them to a monitoring system.

[0056] Calculating the Round-Trip Time (RTT) measurement based on send and receive timestamps transforms raw timestamp data into a key metric for measuring network latency. RTT refers to the total time it takes for a data packet to travel from the sender to the receiver, through network transmission, and then back to the sender via an acknowledgment. If the send and receive timestamps are unidirectional, the RTT can be understood as the unidirectional delay, i.e., the delivery time minus the send time. To obtain a more accurate round-trip time, a probe packet can be sent from the sender, and an acknowledgment packet can be sent immediately upon receipt by the receiver. The sender then calculates the RTT by subtracting the time it took to send the probe packet from the time it received the acknowledgment. Alternatively, it can be calculated using a request-response pattern within the service call chain. For example, when a request packet is sent, the send time is recorded; when the corresponding response packet is received, the receive time is recorded. The difference between the two is the RTT of one service interaction.

[0057] Calculating the absolute difference between consecutive RTT measurements can be achieved by maintaining a queue or buffer of RTT measurements. When a new RTT measurement is calculated, it is compared to the previous RTT measurement, and the absolute value of the difference is taken as the current jitter data. For example, Jitter = |RTT_n - RTT_n-1|. This method can capture rapid fluctuations in network latency.

[0058] This application's solution provides foundational data for subsequent network latency calculations by acquiring the sending and receiving timestamps of data packets. Based on these precise timestamps, the executing entity can calculate the corresponding RTT (Round-Trip Time) measurement, transforming the raw time information into a quantifiable network transmission latency indicator. Furthermore, by calculating the absolute difference between consecutive RTT measurements, this solution can directly and effectively quantify network jitter data. This method avoids vague or subjective judgments about network jitter, instead providing an objective quantitative indicator based on actual data packet transmission latency changes. The precise network jitter data obtained in this way can serve as a key component of the service call link data, providing reliable input for subsequent jitter root cause analysis, thereby making the entire network jitter diagnosis process more accurate and efficient. This precise jitter data calculation method enables the acquisition of high-quality jitter information upon data packet confirmation, significantly improving the effectiveness of the overall diagnostic method.

[0059] The following example illustrates this. Assume a TCP / IP-based service call chain. When a client sends a request packet to a server, the client records the sending time, for example, T1. When the server receives and processes the request packet, it sends a response packet to the client. The client receives the response packet and records the arrival time, for example, T2. At this point, a one-way delay or approximate RTT measurement can be calculated, for example, RTT_A = T2 - T1. In subsequent service interactions, the client sends another request and receives a response, obtaining another RTT measurement, for example, RTT_B. The network jitter data can then be calculated as |RTT_B - RTT_A|. For example, if RTT_A is 50ms and RTT_B is 60ms, the jitter data is 10ms. If RTT_B is 45ms, the jitter data is 5ms. This sending and receiving time information can be recorded when data packets are sent and received by adding a timestamp field to the application layer protocol or by using precise time functions provided by the operating system (such as `gettimeofday` or `QueryPerformanceCounter`).

[0060] Through the above technical solution, this application provides a precise and quantifiable method for calculating network jitter data. This method effectively captures instantaneous fluctuations in network latency by directly measuring the transmission and arrival times of data packets and calculating the absolute difference based on continuous round-trip time measurements. This precise jitter data provides high-quality input for subsequent root cause analysis of jitter in service call links, significantly improving the accuracy and reliability of network jitter diagnosis, avoiding misjudgments or omissions caused by inaccurate jitter data, and thus improving the efficiency of network fault location and resolution.

[0061] Referring to Figure 3, in one embodiment, the specific method for embedding network jitter data into service call link data includes, but is not limited to, steps S301 to S302.

[0062] Step S301: Encapsulate the network jitter data into OTel data format to obtain the encapsulated network jitter data.

[0063] Step S302: The encapsulated network jitter data is embedded into the service call link data as either Metric data or Span Attribute data to obtain the embedded link data.

[0064] Encapsulating network jitter data in OTel format aims to provide a standardized data representation, enabling seamless integration of network jitter data with business call chain data, facilitating subsequent unified collection, transmission, storage, and analysis. One implementation method is to utilize the APIs provided by the OpenTelemetry SDK to construct structured data objects conforming to the OTel specification from the calculated network jitter data, such as events or attributes of OTel Spans, or values ​​of OTelMetrics. Another implementation method is to use a custom data converter or adapter to convert the raw network jitter data into formats such as JSON or Protobuf, ensuring that its field naming and structure conform to the semantic conventions of OpenTelemetry, so that it can be recognized and processed by the OpenTelemetry Collector or other compatible components. The encapsulated network jitter data refers to network jitter data encapsulated in OTel format. Its role is to serve as a standardized data unit that can be understood and processed by existing observability systems, facilitating its effective embedding into the business call chain. This encapsulation ensures data consistency and interoperability.

[0065] Generate encapsulated network jitter data. By embedding this data as metric or Span attribute data, network performance data can be tightly integrated with business transaction data. This allows for direct viewing and analysis of network jitter within the business context (such as an API call or a microservice request) during jitter root cause analysis. When embedded as metric data, the encapsulated network jitter data can be sent as an independent metric stream to the observability backend and associated with business call chain data using common tags. For example, a metric named `network.jitter.rtt_diff` can be defined, with its value being network jitter data and tags such as `service.name` and `endpoint.id`. When embedded as Span attribute data, the encapsulated network jitter data can be directly added as key-value pairs to the attribute set of a Span in the business call chain. For example, attributes such as `network.jitter.value: 10ms` and `network.jitter.source: client` can be added to a Span of an HTTP request.

[0066] The proposed solution encapsulates the calculated network jitter data into an OTel data format, giving it standardized characteristics that allow for widespread identification and processing. Subsequently, this standardized, encapsulated network jitter data is flexibly embedded into the business call chain data as metric data or span attribute data, depending on actual needs and system architecture. This embedding method ensures that network jitter information is no longer isolated data, but is closely associated with specific business operations, service calls, or network requests. When performing jitter root cause analysis on the business call chain data, network jitter information related to specific business processes can be directly obtained from the chain data. This allows for simultaneous analysis of business performance and network performance from a unified view, quickly locating the specific business context and network path where jitter occurs, significantly improving the efficiency and accuracy of jitter diagnosis.

[0067] The following example illustrates this. In a distributed system, when a user initiates a request, this request is processed by multiple microservices, forming a business call chain. When microservice A sends a network request to microservice B, microservice A calculates the network jitter data during the transmission of this data packet. To associate this jitter data with the business chain, microservice A can encapsulate the network jitter data in OTel data format. For example, it can be used as an attribute of the Span corresponding to the current business request, named `network.jitter.rtt_deviation`, and assigned the calculated jitter value. Alternatively, microservice A can also use this jitter data as an OTel metric, such as a Gauge type metric, with labels such as the current service name and the target service name. In this way, when the tracing data of the entire business call chain is collected on the observability platform, the network jitter data is already embedded in the corresponding business Span or associated metric, allowing the network jitter status of each link to be directly seen when viewing the business chain.

[0068] The above technical solution encapsulates network jitter data into OTel data format and embeds it as metric data or span attribute data into the business call chain data, solving the problem of the difficulty in effectively associating traditional jitter data with business data. This standardized embedding method allows network jitter information to be tightly integrated with specific business transactions, service calls, or network requests, enabling the direct identification and location of jitter issues within the business context during jitter root cause analysis. This significantly improves the efficiency and accuracy of jitter diagnosis, avoids the tedious process of manually associating data between different systems, and allows operations and maintenance personnel to more quickly discover and resolve network performance issues affecting user experience.

[0069] Referring to Figure 4, in one embodiment, the specific method for performing jitter root cause analysis on embedded link data includes, but is not limited to, steps S401 to S404.

[0070] Step S401: Summarize the data of each embedded link within the preset time period.

[0071] Step S402: Perform jitter feature relationship analysis on the embedded link data to obtain jitter relationship features that characterize the relationship between network jitter, service transactions and terminals during a single data transmission.

[0072] Step S403: Perform jitter feature correlation analysis on each jitter relationship feature to obtain jitter correlation features used to characterize the correlation relationship between the topologies of each jitter relationship feature.

[0073] Step S404: Generate network jitter diagnosis results based on jitter correlation features.

[0074] When aggregating embedded link data within a preset time frame, a fixed time window can be set, such as 5 minutes or 10 minutes. The execution entity periodically collects and stores all embedded link data generated within this time window. Alternatively, the preset time frame can be dynamically adjusted based on business load or system events. For example, when abnormal jitter is detected, the time frame can be automatically shortened for more detailed analysis, or the time frame can be extended when the system is stable to reduce processing overhead.

[0075] When performing jitter feature relationship analysis on embedded link data, the embedded link data can be parsed to identify network jitter data, service transaction identifiers, and terminal identity information. These three elements can then be associated one-to-one to form a tuple or structure as the jitter relationship feature. Alternatively, a graph database or relational database can be used, with network jitter, service transactions, and terminals as nodes and their relationships as edges, to construct a local relationship graph. A specific subgraph or path of this graph represents the jitter relationship feature.

[0076] When performing jitter feature correlation analysis on various jitter relationship features, multiple jitter relationship features can be aggregated or linked based on common business transactions or common terminals in the jitter relationship features to construct a sequence or graph structure representing the jitter propagation in the business call chain. Alternatively, pattern matching algorithms can be used to identify recurring patterns or abnormal sequences in multiple jitter relationship features, thereby inferring the correlation between jitter in different business links or terminals.

[0077] When generating network jitter diagnostic results based on jitter correlation features, a text report can be generated based on the abnormal patterns or key nodes identified in the jitter correlation features, indicating the business transactions, terminals, or network paths that may have jitter issues. Alternatively, visualization techniques can be used to present the jitter correlation features graphically, such as topology maps or heatmaps, to intuitively show the scope and root causes of jitter.

[0078] This application's solution achieves precise root cause localization of jitter in the aforementioned embedded link data through a systematic, multi-stage analysis process. First, by aggregating data from each embedded link within a preset timeframe, the comprehensiveness of the analysis and the ability to capture jitter trends are ensured, avoiding diagnostic blind spots caused by data fragmentation. Subsequently, jitter feature relationship analysis is performed on these aggregated embedded link data, organically combining the discrete network jitter, business transactions, and terminal information in the original data to form jitter relationship features with clear semantics. This allows jitter events in a single data transmission to be clearly understood and tracked. Based on this, further jitter feature correlation analysis is conducted on each jitter relationship feature. By identifying the topological relationships between different jitter relationship features, the propagation path and impact range of jitter in the entire business call chain are revealed, thus enabling a macro-level understanding of the root cause of jitter. Finally, based on these in-depth analysis-derived jitter correlation features, instructive network jitter diagnostic results are generated. The entire process transforms raw, scattered jitter data into structured, correlated diagnostic information, greatly improving the depth and accuracy of jitter root cause analysis and effectively solving the problem of difficulty in accurately identifying jitter root causes in complex business scenarios.

[0079] The following is a concrete example. Suppose an online video conferencing system experiences buffering issues reported by users. The executing entity first calculates and embeds network jitter data into the business call chain data according to the method described above. To diagnose the root cause of the buffering, the proposed solution first summarizes all embedded chain data related to the video conference over the past 10 minutes. Next, jitter feature relationship analysis is performed on these embedded chain data. For example, for each video data packet transmission, the executing entity extracts its corresponding network jitter data, the video conference session ID (as business transaction data), and the participating user's device ID (as terminal identity data), thus obtaining a series of jitter relationship features, such as (high jitter value, session ID_A, user device ID_X). Subsequently, the executing entity performs jitter feature correlation analysis on these jitter relationship features. For example, if multiple jitter relationship features are found to point to session ID_A, and most of the high jitter is associated with user device ID_X, or with a specific video streaming server, then the executing entity can construct the propagation path of jitter from user device X to server Y in session A. Based on these jitter correlation characteristics, the executing entity can generate network jitter diagnostic results, such as indicating that "there is continuous high jitter in the network path between user device ID_X and video stream server Y, which may be the root cause of the stuttering."

[0080] Through the above technical solutions, this application provides a structured and systematic method for network jitter root cause analysis. This method ensures comprehensive analysis by summarizing embedded link data within a preset time period; it clarifies the relationship between network jitter, business transactions, and terminals through jitter feature relationship analysis, enabling precise tracking of jitter events in single transmissions; furthermore, it reveals the propagation path and topological relationships of jitter in complex business call links through jitter feature correlation analysis, thereby enabling a holistic understanding of the impact scope and underlying causes of jitter. Finally, based on these multi-level analysis results, highly accurate and instructive network jitter diagnostic results can be generated, effectively solving the technical challenge of traditional methods' difficulty in quickly and accurately locating the root cause of network jitter in complex network environments, and significantly improving the efficiency and accuracy of fault diagnosis.

[0081] In some embodiments, jitter feature relationship analysis is performed on the embedded link data, including: extracting network jitter data, transaction data, and terminal identity data from the embedded link data; and associating the extracted network jitter data, transaction data, and terminal identity data to obtain jitter association features.

[0082] Transaction data refers to information related to business operations or service requests, such as business request identifiers, service names, operation types, and start and end times, used to identify and track specific business processes. Terminal identity data refers to the unique identification information of the terminal device initiating a business request or receiving data packets, such as IP address, device MAC address, user identifier, and device model, used to distinguish different terminal devices. Extracting network jitter data, transaction data, and terminal identity data from embedded link data can be achieved by parsing specific fields or tags in the embedded link data. For example, if the embedded link data is in JSON or XML format, it can be obtained through key-value pair lookups or XPath queries; alternatively, it can be extracted by using regular expression matching or machine learning models to perform pattern recognition on unstructured text data.

[0083] The network jitter data, transaction data, and terminal identity data obtained through correlation extraction can be matched and aggregated using common identifiers (such as timestamps and request identifiers). For example, network jitter data within the same time window and under the same business request identifier can be bound to the corresponding terminal identity data. Alternatively, a multi-dimensional data model can be constructed, treating network jitter data, transaction data, and terminal identity data as different dimensions, and establishing the correlation between them through data pivoting or cross-analysis.

[0084] This application's solution first accurately identifies and separates values ​​related to network jitter, transaction information related to specific business operations, and the unique identifier of the terminal device initiating or involved in the business operation from the received embedded link data. Subsequently, these independently extracted network jitter data, transaction data, and terminal identity data are logically bound and mapped. This association process ensures that each network jitter event can be traced back to the specific business transaction and corresponding terminal device, thus forming a jitter association feature with a clear causal or correlational indication. In this way, it is possible to clearly reveal how network jitter interacts with specific business transactions and specific terminal devices during a single data transmission, providing refined foundational data for subsequent jitter root cause analysis. This mechanism effectively solves the problem of how to extract precise correspondences between jitter, business, and terminals from massive amounts of link data, making jitter feature relationship analysis no longer a vague statistical exercise, but a precise characterization based on specific events.

[0085] As a specific implementation, when the executing entity receives embedded link data containing network jitter information, such as OpenTelemetry Span data, this Span data may include network jitter data (e.g., `network.jitter.rtt_diff`), transaction data (e.g., `business.transaction.id`, `service.name`), and terminal identity data (e.g., `client.ip`, `user.agent`) in its Span Attributes. In this case, a data parsing module can be configured to identify and extract these predefined or agreed-upon attribute fields. For example, network jitter data can be obtained by reading the `network.jitter.rtt_diff` field, transaction data by reading the `business.transaction.id` and `service.name` fields, and terminal identity data by reading the `client.ip` field. Once this data is extracted, the executing entity can create an internal data structure, such as a tuple or object, to encapsulate the extracted network jitter data, transaction data, and terminal identity data as its members. For example, a record called `JitterRelationship(network_jitter_value, transaction_id, client_ip)` can be created. This record constitutes a jitter correlation feature used to characterize the relationship between network jitter, business transactions, and terminals during a single data transmission.

[0086] Through the above technical solution, this application can accurately identify and extract network jitter data, transaction data, and terminal identity data from complex embedded link data, and effectively correlate them. This explicit data extraction and correlation mechanism makes the jitter feature relationship analysis process more refined and accurate, avoiding diagnostic biases caused by data confusion or unclear correlations. Therefore, it can generate more targeted and interpretable jitter correlation features, providing a solid data foundation for subsequent jitter root cause analysis and significantly improving the accuracy and efficiency of network jitter diagnosis.

[0087] In some embodiments, jitter feature association analysis is performed on each jitter relationship feature, including: forming a business transaction group based on the transaction data in each jitter relationship feature; determining the initial business transaction in the business transaction group based on the time information of the transaction data; and associating the transaction data, network jitter data and terminal identity data corresponding to the initial business transaction to obtain jitter association features.

[0088] A business transaction group refers to the logical aggregation of jitter relationship characteristics that have the same or related transaction data (e.g., different sub-transactions belonging to the same end-to-end business process). One possible implementation is to categorize all jitter relationship characteristics with the same ID into the same business transaction group by parsing the unique business ID or trace ID in the transaction data. Another possible implementation is to organize multiple related jitter relationship characteristics constituting a complete business process into a business transaction group by analyzing the parent-child relationships or call chain relationships in the transaction data.

[0089] An initial business transaction refers to the business transaction within a business transaction group that serves as the starting point for the entire business process or sub-process. One possible implementation is to compare the start times of all transactions within each business transaction group and identify the transaction with the earliest start time as the initial business transaction. Another possible implementation is to identify transactions without upstream dependencies as the initial business transaction based on the topology of the business call chain.

[0090] Jitter correlation features refer to the comprehensive characteristics that characterize jitter issues at the beginning of a business process, obtained by associating relevant data from the initial business transaction. These features include the business context at the time of jitter, the amount of jitter, and the terminal information involved. One possible implementation is to use the unique identifier of the initial business transaction as the primary key, retrieving and merging the corresponding information from stored network jitter data and terminal identity data. Another possible implementation is to construct a data structure that encapsulates the transaction ID of the initial business transaction, its corresponding network jitter value, and the terminal ID that initiated the transaction as fields.

[0091] This application's solution addresses the challenge of root cause localization of jitter in complex business call chains by conducting more refined correlation analysis of jitter relationship features. Specifically, when performing jitter feature correlation analysis on various jitter relationship features, firstly, based on the transaction data contained in each jitter relationship feature, jitter relationship features belonging to the same end-to-end business process or having strong correlations are aggregated to form business transaction groups. This step effectively organizes scattered jitter events into logically meaningful units, laying the foundation for subsequent analysis. Next, within each formed business transaction group, the initial business transaction in the group is accurately determined using the time information of the transaction data. By identifying the starting point of the business process, the source of the jitter problem can be effectively traced, rather than simply focusing on its propagation in the chain. Finally, the transaction data, network jitter data, and terminal identity data corresponding to the initial business transaction are correlated to obtain jitter correlation features. This correlation method ensures that the jitter correlation features not only include the jitter quantity itself but also the business context at the time of jitter occurrence and the terminal information that initiated the jitter, thus forming a comprehensive and causally-oriented diagnostic basis. Through the above steps, the solution of this application can systematically identify and analyze network jitter starting from the beginning of the business process, thereby more accurately locating the root cause of jitter and revealing the propagation path of jitter in the business process.

[0092] The following is a concrete example to illustrate this. Suppose an online shopping system where a user's journey from browsing products to final payment involves multiple microservice calls, such as product service, shopping cart service, order service, and payment service. During the payment process, multiple network jitter events may occur, each corresponding to a jitter relationship characteristic. First, the executing entity groups these jitter relationship characteristics into a "payment transaction group" based on the transaction data (e.g., all these service calls share a unique transaction ID). Next, the executing entity analyzes the timing information of each transaction within this payment transaction group. For example, the order service call starts earliest, followed by the payment service call. At this point, the executing entity determines the "order service call" as the initial transaction in this group, as it represents the starting point of the payment process. Finally, the executing entity correlates the transaction data corresponding to the "order service call" (e.g., order ID, service name), the generated network jitter data (e.g., RTT jitter value), and the user terminal identity data initiating the payment operation (e.g., user ID, IP address) to obtain a comprehensive jitter correlation characteristic. This jitter correlation feature clearly indicates which terminal initiated which business transaction experienced network jitter at the beginning of the payment process, providing a clear starting point for subsequent root cause analysis.

[0093] Through the above technical solution, this application can closely integrate dispersed network jitter events with specific business processes and their starting points, thereby more effectively identifying and tracing the propagation path of network jitter between different business transactions in complex distributed systems. By accurately identifying the initial business transaction in a business transaction group and correlating its related data, the accuracy and efficiency of jitter root cause analysis can be significantly improved, avoiding blind investigation in a large business call chain, making the diagnostic results more targeted, and thus enabling faster location and resolution of network jitter problems.

[0094] In some embodiments, generating network jitter diagnostic results based on jitter correlation features includes: identifying abnormal terminals causing network jitter based on jitter correlation features; displaying a three-dimensional heatmap describing the link relationship between network jitter, service transactions, and terminals; and marking abnormal terminals and service call links containing abnormal terminals in the three-dimensional heatmap as network jitter diagnostic results.

[0095] Identifying abnormal terminals causing network jitter can be achieved by analyzing the jitter contribution or jitter anomaly index of each terminal in jitter correlation features. For example, it can be done by counting the number of times or the magnitude of jitter data in related business transactions of a certain terminal is significantly higher than the average level within a specific time period, thereby marking it as an abnormal terminal. Alternatively, a threshold can be set, and when the jitter intensity, frequency, or duration exhibited by a terminal in jitter correlation features exceeds a preset threshold, it can be automatically identified as an abnormal terminal.

[0096] A 3D heatmap depicting the relationship between network jitter, business transactions, and endpoints is used to graphically present data on these three key dimensions, helping users understand the complex relationships between them. Its purpose is to provide a macroscopic and intuitive perspective, enabling users to quickly grasp the jitter distribution and potential problem areas throughout the entire business call chain. The three axes of this 3D heatmap can represent endpoints, business transactions, and time, respectively, while the color or brightness of the heatmap indicates the intensity of network jitter at the corresponding location; for example, darker or brighter colors indicate more severe jitter. Alternatively, two axes of the 3D heatmap can represent endpoints and business transactions, and the third dimension (e.g., height or color) can represent jitter intensity, while changes over time can be displayed through animation or time slices.

[0097] In a 3D heatmap, annotating abnormal terminals and their associated service call chains can be achieved by changing the terminal's color, shape, or size, or by adding visual cues such as highlighted borders or blinking effects around it. Simultaneously, the service call chains related to the abnormal terminal can be highlighted using different line colors, thicknesses, or solid / dashed lines. Furthermore, when the mouse hovers over or clicks on an abnormal terminal in the 3D heatmap, a detailed information dialog box can automatically pop up, highlighting its related service call chains, providing an interactive annotation experience.

[0098] This application's solution, based on jitter root cause analysis of embedded link data and the acquisition of jitter correlation features, further optimizes the presentation of diagnostic results. First, based on the obtained jitter correlation features, the executing entity accurately identifies the specific abnormal terminals causing network jitter by deeply analyzing the jitter data generated by each terminal in the service call link. This process establishes a direct link between abstract jitter data and specific physical entities, providing clear targets for subsequent troubleshooting. Subsequently, to present the complex link relationships between network jitter, service transactions, and terminals to users in an easily understandable way, a three-dimensional heatmap is generated and displayed. This heatmap visually shows the intensity and distribution of jitter for different terminals in different service transactions, enabling operations personnel to grasp the overall health of the network from a macro perspective. Furthermore, to ensure users can quickly locate problems, the executing entity prominently marks the previously identified abnormal terminals in the three-dimensional heatmap and simultaneously highlights all service call links containing those abnormal terminals. In this way, users can not only see where jitter exists but also immediately identify which terminal caused the jitter and which specific service processes were affected by it. This combination of visualization and key annotation makes the originally scattered and difficult-to-understand jitter diagnosis information centralized, intuitive and operable, which greatly improves the efficiency and accuracy of network fault diagnosis and effectively solves the pain point that it is difficult to quickly locate the problem with only abstract diagnosis results.

[0099] The following is a concrete example to illustrate this. After completing the jitter root cause analysis of the embedded link data and generating jitter correlation features, the executing entity can first analyze these jitter correlation features. For example, by calculating the frequency and average amplitude of jitter data exceeding a preset alarm threshold for each terminal across all relevant business transactions. If the jitter frequency or average amplitude of a certain terminal is significantly higher than that of other terminals, or exceeds a specific baseline, it is identified as an abnormal terminal causing network jitter. For example, if terminal A experienced high-intensity jitter in 70% of the business transactions it participated in over the past hour, while the proportion of other terminals was less than 20%, then terminal A is identified as an abnormal terminal. Subsequently, the executing entity generates a three-dimensional heatmap. The X-axis of this heatmap can represent different terminals, the Y-axis can represent different business transactions, and the Z-axis can represent slices in the time dimension. The color intensity or brightness in the heatmap can be used to represent the network jitter intensity at a specific terminal, a specific business transaction, and a specific time point, for example, a gradient from blue (low jitter) to red (high jitter). Once the 3D heatmap is displayed, the system will automatically highlight previously identified abnormal terminals. For example, the location of abnormal terminal A on the X-axis will be surrounded by a flashing red border, or the color saturation of all its corresponding heatmap tiles will be significantly increased. Simultaneously, all business call chains passing through abnormal terminal A—that is, business transaction chains interacting with terminal A on the Y-axis—will be marked with bold dashed lines or different highlight colors (such as bright yellow). This allows operations personnel to immediately see which terminal is the source of the problem and which specific business processes it affects, thus enabling rapid initiation of troubleshooting and repair work.

[0100] Through the above technical solution, after obtaining the jitter correlation characteristics, this application can transform abstract diagnostic results into intuitive and operable fault location information. By identifying abnormal terminals and prominently marking them on a 3D heatmap, while highlighting the affected service call links, maintenance personnel can quickly identify the specific source of network jitter and its impact range. This visualization and highlighting method greatly reduces the complexity of fault diagnosis, shortens fault location time, thereby improving the efficiency and accuracy of network operation and maintenance, and effectively avoiding the difficulties and delays caused by non-intuitive diagnostic results.

[0101] Referring to Figure 5, this application embodiment also provides a network jitter diagnosis device that can implement the above-mentioned network jitter diagnosis method. The device includes: a first module 501, used to calculate network jitter data when the data packet is confirmed to have been delivered; a second module 502, used to embed the network jitter data into the service call link data to obtain embedded link data; and a third module 503, used to perform jitter root cause analysis on the embedded link data to obtain network jitter diagnosis results.

[0102] The specific implementation of this network jitter diagnostic device is basically the same as the specific embodiment of the network jitter diagnostic method described above, and will not be repeated here.

[0103] Figure 6 is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application.

[0104] The electronic device 600 according to this embodiment of the present disclosure will now be described with reference to FIG6. The electronic device 600 shown in FIG6 is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present disclosure.

[0105] As shown in Figure 6, the electronic device 600 is presented in the form of a general-purpose computing device. The components of the electronic device 600 may include, but are not limited to: at least one processing unit 610, at least one storage unit 620, a bus 630 connecting different system components (including storage unit 620 and processing unit 610), a display unit 640, etc.

[0106] The storage unit stores program code, which can be executed by the processing unit 610, causing the processing unit 610 to perform the steps described in the above-described network jitter diagnosis method section of this specification according to various exemplary embodiments of this disclosure.

[0107] Storage unit 620 may include a readable medium in the form of a volatile storage unit, such as random access memory (RAM) 6201 and / or cache memory 6202, and may further include a read-only memory (ROM) 6203.

[0108] Storage unit 620 may also include a program / utility 6204 having a set (at least one) program module 6205, such program module 6205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0109] Bus 630 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0110] Electronic device 600 can also communicate with one or more external devices 600' (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 600, and / or with any device that enables electronic device 600 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 650. Furthermore, electronic device 600 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 660. Network adapter 660 can communicate with other modules of electronic device 600 via bus 630. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 600, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0111] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0112] The network jitter diagnosis method, apparatus, device, and medium provided in this application calculate network jitter data upon confirmation of data packet delivery, embeds the calculated network jitter data into service call link data, and performs root cause analysis to obtain corresponding network jitter diagnosis results. Therefore, by effectively embedding the calculated network jitter data with service call link data, a deep integration of network performance indicators and service context is achieved. This makes network jitter data no longer an isolated number, but closely related to specific service operations, service call paths, and end users, allowing for precise association between network jitter and affected users, and clearly identifying the impact of network jitter on services.

[0113] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the methods described above according to the embodiments of this disclosure.

[0114] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0115] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0116] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0117] Exemplary embodiments of this disclosure have been specifically shown and described above. It should be understood that this disclosure is not limited to the detailed structures, arrangements, or implementations described herein; rather, this disclosure is intended to cover various modifications and equivalent arrangements contained within the spirit and scope of the appended claims.

Claims

1. A method for diagnosing network jitter, characterized in that, include: Calculate network jitter data when data packets are confirmed to have been delivered; The network jitter data is embedded into the service call link data to obtain the embedded link data; The embedded link data is subjected to jitter root cause analysis to obtain network jitter diagnosis results.

2. The network jitter diagnosis method according to claim 1, characterized in that, The calculation of network jitter data includes: acquiring the sending time information and delivery time information of the data packet; calculating the corresponding RTT measurement value based on the sending time information and the delivery time information; and calculating the absolute difference between consecutive RTT measurement values ​​to obtain the network jitter data.

3. The network jitter diagnosis method according to claim 1, characterized in that, The step of embedding the network jitter data into the service call link data includes: encapsulating the network jitter data into OTel data format to obtain encapsulated network jitter data; and embedding the encapsulated network jitter data as metric data or as span attribute data into the service call link data to obtain the embedded link data.

4. The network jitter diagnosis method according to claim 1, characterized in that, The step of performing jitter root cause analysis on the embedded link data includes: summarizing the embedded link data within a preset time period; performing jitter feature relationship analysis on the embedded link data to obtain jitter relationship features that characterize the relationship between network jitter, service transactions, and terminals during a single data transmission; performing jitter feature correlation analysis on each of the jitter relationship features to obtain jitter correlation features that characterize the correlation between the topologies of each of the jitter relationship features; and generating the network jitter diagnosis result based on the jitter correlation features.

5. The network jitter diagnosis method according to claim 4, characterized in that, The step of performing jitter feature relationship analysis on the embedded link data includes: extracting network jitter data, transaction data, and terminal identity data from the embedded link data; and associating the extracted network jitter data, transaction data, and terminal identity data to obtain the jitter association features.

6. The network jitter diagnosis method according to claim 4, characterized in that, The step of performing jitter feature association analysis on each of the jitter relationship features includes: forming a business transaction group based on the transaction data in each of the jitter relationship features; determining the initial business transaction in the business transaction group based on the time information of the transaction data; and associating the transaction data, network jitter data, and terminal identity data corresponding to the initial business transaction to obtain the jitter association feature.

7. The network jitter diagnosis method according to claim 4, characterized in that, The step of generating the network jitter diagnosis result based on the jitter association features includes: identifying the abnormal terminal causing the network jitter based on the jitter association features; displaying a three-dimensional heatmap describing the link relationship between network jitter, service transactions, and the terminal; and marking the abnormal terminal and the service call link containing the abnormal terminal in the three-dimensional heatmap as the network jitter diagnosis result.

8. A network jitter diagnostic device, characterized in that, include: The first module is used to calculate network jitter data when a data packet is confirmed to have been delivered; The second module is used to embed the network jitter data into the service call link data to obtain embedded link data; the third module is used to perform jitter root cause analysis on the embedded link data to obtain network jitter diagnosis results.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the network jitter diagnosis method according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the network jitter diagnosis method according to any one of claims 1 to 7.

Images