Method, device and computer program product for monitoring connection status

Abstract

This disclosure relates to methods, apparatus, and computer program products for monitoring connection status. The method includes a capture task that sends data packets associated with a received user request to multiple nodes. The method also includes receiving the captured data packets from the multiple nodes. The method further includes determining information about the source end of the data packets, information about the destination end, and operational information about the connection between the source and destination ends. The method also includes monitoring the connection status based on at least one of the data packets, source end information, destination end information, and operational information. In this way, information about each communication endpoint within a node and its connections can be comprehensively captured, providing more detailed and accurate data, thereby more accurately identifying the connection status, locating the root cause of connection performance problems, and formulating targeted optimization strategies.

Description

Technical Field

[0001] This disclosure relates to the field of computers, and more specifically, to methods, apparatus, and computer program products for monitoring connection status. Background Technology

[0002] Distributed database (DD) scaling systems are an important component of modern information technology, achieving scalability and high availability by distributing data across multiple nodes in a network. In DD scaling systems, multiple services typically perform specific data processing tasks to support the overall system operation. Since the efficiency and performance of inter-service communication directly impact the overall system response speed and user experience, it is necessary to monitor and analyze the performance of inter-service communication.

[0003] Several tracing tools exist that can track individual data packets between services, aiding in network problem diagnosis and performance optimization. Additionally, tools exist that analyze average latency between services and visualize system topology, allowing system administrators to intuitively identify bottlenecks in inter-service interactions. Summary of the Invention

[0004] Embodiments of this disclosure provide a method, apparatus, and computer program product for monitoring connection status.

[0005] In a first aspect of the embodiments of this disclosure, a method for monitoring connection status is provided. The method includes sending a data packet capture task associated with a received user request to a plurality of nodes. The method also includes receiving the captured data packets from the plurality of nodes. The method further includes determining information about the source end of the data packets, information about the destination end, and operational information about the connection between the source end and the destination end. The method also includes monitoring the connection status based on at least one of the data packets, the source end information, the destination end information, and the operational information.

[0006] In a second aspect of embodiments of this disclosure, an electronic device is provided. The electronic device includes one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement a method for monitoring connection status. The method includes sending a packet capture task associated with a received user request to a plurality of nodes. The method also includes receiving the captured packets from the plurality of nodes. The method further includes determining information about the source end of the packets, information about the destination end, and operational information about the connection between the source end and the destination end. The method also includes monitoring the status of the connection based on at least one of the packets, the source end information, the destination end information, and the operational information.

[0007] In a third aspect of embodiments of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements a method for monitoring connection status. The method includes sending a data packet capture task associated with a received user request to a plurality of nodes. The method also includes receiving the captured data packets from the plurality of nodes. The method further includes determining information about the source end of the data packets, information about the destination end, and operational information about the connection between the source end and the destination end. The method also includes monitoring the status of the connection based on at least one of the data packets, the source end information, the destination end information, and the operational information.

[0008] It should be understood that the description in the Summary of the Invention section is not intended to limit the key or essential features of the embodiments of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0009] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0010] Figure 1 A schematic diagram of an example environment in which several embodiments of the present disclosure may be implemented is shown;

[0011] Figure 2 A flowchart of a method for monitoring connection status according to some embodiments of the present disclosure is shown;

[0012] Figure 3A A schematic diagram of the architecture of a tracing service for monitoring connection status according to some embodiments of the present disclosure is shown;

[0013] Figure 3B A schematic diagram illustrating the connections between clients, services, and container groups (Pods) in multiple nodes according to some embodiments of this disclosure is shown;

[0014] Figure 3C A schematic diagram of a query table including information about Pods and services according to some embodiments of this disclosure is shown;

[0015] Figure 3D A schematic diagram of an operation tracking table according to some embodiments of the present disclosure is shown;

[0016] Figure 4 A flowchart is shown illustrating a method for monitoring connectivity performance and diagnosing faults according to some embodiments of the present disclosure;

[0017] Figure 5A schematic diagram illustrating a process for capturing data packets according to some embodiments of the present disclosure is shown;

[0018] Figure 6 Schematic diagrams illustrating the calculation of input / output (IO) latency values ​​and throughput according to some embodiments of this disclosure are shown; and

[0019] Figure 7 A block diagram of a device that can implement several embodiments of the present disclosure is shown. Detailed Implementation

[0020] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0021] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0022] As mentioned above, although existing technologies possess tools capable of tracing packets from individual connections between services, these tools are typically limited to a single connection perspective. In the complex environment of DD extended systems, connections between services often span multiple nodes, traversing complex routing paths and proxies. Therefore, tracing packets from only a single connection makes it difficult to comprehensively capture the full picture of inter-service communication, and also fails to provide sufficient intelligent diagnostic information for complex routing and proxy scenarios.

[0023] Meanwhile, while tools exist that can visualize system topology, these tools rely on macroscopic metrics such as average latency and lack finer-grained data support. In systems like DD extensions, performance issues might stem from minute latency differences or specific routing paths. Due to the lack of comprehensive data support, these tools cannot help system administrators more accurately pinpoint the root cause of problems and develop targeted optimization strategies.

[0024] To address this, embodiments of this disclosure propose a scheme for monitoring connection status. The method involves sending a data packet capture task associated with a user request to multiple nodes. After receiving the captured data packets, the source information, destination information, and operational information of the connection between the source and destination are determined. Finally, based on this information, the connection status is monitored. This approach comprehensively captures information about each communication endpoint and its connection within a node, providing more detailed and accurate data. This allows for more precise identification of connection status, pinpointing the root cause of connection performance problems, and developing targeted optimization strategies.

[0025] Figure 1 A schematic diagram of an example environment 100 in which various embodiments of this disclosure may be implemented is shown. For example... Figure 1 As shown, the example environment 100 may include multiple nodes, such as node 101-1, node 101-2, and node 101-N. Nodes can be physical devices, such as computers, servers, routers, etc., or logical entities, such as software processes, virtual machines, containers, etc. In some embodiments, node 101-1, node 101-2, and node 101-N may be nodes in a DD extended system, nodes in other types of clusters, or may not belong to any cluster and act as independent computing entities. Node 101-1, node 101-2, and node 101-N can be independent entities participating in system operation and possessing computing and communication capabilities.

[0026] In this embodiment, a connection status monitor 115 can accept user requests. The connection status monitor 115 can be a module with computing and data processing capabilities, responsible for receiving requests from users. User requests may include specific operations or tasks that the user wants the system to perform, such as data querying, data updating, or service invocation. To respond to user requests, the connection status monitor 115 can rely on the computing units within the node to process the user requests. The processing involves communication between the client, services within the node, and Pods within the node. To effectively monitor the system's processing of user requests, the connection status monitor 115 can send a capture task of data packets 105 associated with the user request to multiple nodes. That is, it captures the data packets 105 that need to be transmitted between communication endpoints. The number of data packets 105 can be one or more, determined by the number of computing units associated with the user request.

[0027] like Figure 1As shown, when the connection status monitor 115 receives data packet 105, it can determine the source information 107 and the destination information 109 of data packet 105 based on the information within data packet 105 itself. The source information 107 and the destination information 109 can be obtained from within the node after determining the source and destination objects of data packet 105. The source information 107 may include the source's Internet Protocol (IP) address, port number, whether it has been destroyed, and whether it needs rescheduling, etc. The destination information 109 may include the destination's IP address, port number, whether it has been destroyed, and whether it needs rescheduling, etc. The source information 107 and the destination information 109 together constitute the basis of connection status monitoring.

[0028] In some embodiments, after determining the information 107 of the source end and the information 109 of the target end, the operation information 113 of the connection 111 between the source end and the target end can also be obtained from the node. The operation information 113 may include whether the connection 111 is interrupted, the sending time of the data packet 105, the response time, whether the transmission is retried, and the amount of IO data, etc. Therefore, the operation information 113 can be used as a benchmark for measuring the network connection status 117.

[0029] In some embodiments, the connection status monitor 115 can monitor the connection status 117 based on one or more of the following: information from data packet 105, source information 107, destination information 109, and operational information 113. Connection status 117 can include the health status of the network connection, performance characteristics, and potential problems. For example, operational information 113 can be used to determine if connection 111 is interrupted. When connection 111 is interrupted, destination information 109 can be used to determine if the interruption was caused by the destruction or rescheduling of the destination. As another example, if the connection status monitor 115 detects frequent retries of data packet 105 based on information from data packet 105 and operational information 113, the network connection may be congested or unstable. In this case, the connection status monitor 115 can further combine information from the source and destination to comprehensively determine the root cause of the problem and take corresponding measures for optimization or repair.

[0030] This method comprehensively captures information about each communication endpoint and its connections, providing more detailed and accurate data. It enables comprehensive and precise monitoring of network connection status, pinpointing the root cause of connection performance problems and providing strong support for stable system operation. Furthermore, this monitoring method is highly flexible and scalable, adaptable to network environments of varying sizes and complexities.

[0031] It should be understood that the architecture and functionality in example environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of this disclosure. Embodiments of this disclosure can also be applied to other environments with different structures and / or functionalities.

[0032] The following will combine Figures 2 to 7 The process of implementing the embodiments of this disclosure is described in detail. For ease of understanding, the specific data mentioned in the following description are exemplary and not intended to limit the scope of protection of this disclosure. It is understood that the embodiments described below may also include additional actions not shown and / or actions shown may be omitted, and the scope of this disclosure is not limited in this respect.

[0033] Figure 2 A flowchart of a method 200 for offloading compressed loads according to some embodiments of the present disclosure is shown. Method 200 can be executed by a connection status monitor in an electronic device, and includes blocks 202, 404, 206, and 208. At block 202, based on a received user request, a data packet capture task associated with the user request is sent to multiple nodes. For example, as... Figure 1 As shown, the connection status monitor 115 can send a capture task of data packets 105 associated with the user request to multiple nodes based on the user request, that is, capture the data packets 105 that need to be transmitted between communication endpoints. The number of data packets 105 can be one or more, which is determined by the number of computing units associated with the user request.

[0034] At box 204, captured data packets are received from multiple nodes. For example, as shown... Figure 1 As shown, when multiple nodes receive a capture task, they can track the connections between multiple services or Pods within the node in real time, thereby capturing data packets 105 associated with user requests, and then sending the captured data packets 105 to the connection status monitor 115.

[0035] In box 206, information about the source end of the data packet, information about the destination end, and operational information about the connection between the source and destination ends are determined. For example, such as... Figure 1As shown, when the connection status monitor 115 receives data packet 105, it can determine the source information 107 and the destination information 109 of data packet 105 based on the information within the data packet 105 itself. For example, the source and destination IP addresses can be determined by identifying the connection to which data packet 105 belongs, thereby determining the source information 107 and the destination information 109. The source information 107 may include the source IP address, port number, whether it has been destroyed, whether it needs to be rescheduled, etc., while the destination information 109 may include the destination IP address, port number, whether it has been destroyed, whether it needs to be rescheduled, etc. The source information 107 and the destination information 109 together constitute the basis of connection status monitoring.

[0036] In some embodiments, after determining the information 107 of the source end and the information 109 of the target end, the operation information 113 of the connection 111 between the source end and the target end can also be obtained from the node. The operation information 113 may include whether the connection 111 is interrupted, the sending time of the data packet 105, the response time, whether the transmission is retried, and the amount of IO data, etc. Therefore, the operation information 113 can be used as a benchmark for measuring the network connection status 117.

[0037] At box 208, the connection status is monitored based on at least one of the following: data packets, source information, destination information, and operational information. For example, ... Figure 1 As shown, the connection status monitor 115 can monitor the connection status 117 based on one or more of the following: information from data packet 105, source information 107, destination information 109, and operational information 113. For example, operational information 113 can be used to determine whether connection 111 is interrupted. When connection 111 is interrupted, destination information 109 can be used to determine whether the interruption was caused by the destruction or rescheduling of the destination. Furthermore, if the connection status monitor 115 detects frequent retries of data packet 105 through information from data packet 105 and operational information 113, the network connection may be congested or unstable. In this case, the connection status monitor 115 can further combine information from the source and destination to comprehensively determine the root cause of the problem and take corresponding measures for optimization or repair.

[0038] This approach comprehensively captures information about each communication endpoint and its connections within a node, providing more detailed and accurate data. It enables comprehensive and precise monitoring of network connectivity, pinpointing the root causes of connection performance issues and providing strong support for stable system operation. Furthermore, this monitoring method is highly flexible and scalable, adaptable to network environments of varying sizes and complexities.

[0039] The following text will refer to Figures 3 to 4. Figure 7The example process of scheduling resources is described in detail. In this disclosure, the embodiments are explained in the order of the architecture of the tracing service for monitoring connection status, the types of connections, the creation of query tables, the creation of runtime tracing tables, the methods for monitoring connection performance and fault diagnosis, the process of capturing data packets, and the calculation of IP latency and throughput. The specific data mentioned in the following description are exemplary and are not intended to limit the scope of this disclosure. It is understood that the embodiments described below may also include additional actions not shown and / or actions shown may be omitted, and the scope of this disclosure is not limited in this respect.

[0040] Figure 3A A schematic diagram of an architecture 300A for a tracing service for monitoring connection status, according to some embodiments of this disclosure, is shown. Figure 3A As shown, the connection status can be monitored by the DD tracing service 301. In this embodiment, the DD tracing service 301 can be used to monitor the connection status of services and / or Pods in the DD extended system. Of course, the architecture of the DD tracing service 301 can also be applied to other systems or clusters, and this disclosure does not limit it. The function of the DD tracing service 301 is similar to... Figure 1 The connection status monitor 115 in the middle is consistent with the function of nodes 307 and 309. Figure 1 The nodes 101-1, 101-2, and 101-N in the table are the same, which will not be elaborated here.

[0041] In some embodiments, the DD tracing service 301 may include a tracing agent 303, which receives data associated with a user request to identify the data packets associated with the user request, and then sends the information of the data packets to be captured to the task controller 305. The task controller 305 may load data packet capture tasks on multiple nodes based on Extended Berkeley Packet Filter (eBPF) technology. After data packets are captured on multiple nodes, the results analyzer 319 may receive the data packets.

[0042] In some embodiments, a service / pod monitor may obtain information about multiple services and multiple pods from multiple nodes before processing a user request, create a query table 313 based on the information about the multiple services and multiple pods, and update the query table 313 at preset intervals (also known as a first preset interval). A connection tracker 315 may also determine the connection associated with the user request and then obtain the connection's runtime information from the nodes to construct a runtime tracking table 317. The runtime tracking table 317 may also be updated at preset intervals (also known as a second preset interval). In this embodiment, the query table 313 may include the IP addresses, port numbers, whether the service and pod have been destroyed, whether rescheduling is required, etc., of multiple services and pods; the runtime tracking table 317 may include whether the connection was interrupted, the packet sending time, the response time, whether the transmission was retried, and the amount of IO data, etc.

[0043] In some embodiments, the result analyzer 319 can monitor and analyze the connection status based on information from captured data packets, lookup table 313, and runtime trace table 317. For example, when the result analyzer 319 receives a data packet, it can determine the connection corresponding to the data packet, then query the runtime trace table 317 to obtain the connection's runtime information, the source address, and the destination address. Finally, it can query the source and destination information in lookup table 313 based on the source and destination addresses to achieve status monitoring. After completing status monitoring and fault diagnosis, the result analyzer 319 can return the analysis results to the trace agent 303.

[0044] Figure 3B A schematic diagram illustrating a connection 300B between clients, services, and container groups (Pods) in multiple nodes according to some embodiments of this disclosure is shown. Figure 3B As shown, the functions of nodes 323 and 335 are... Figure 1Nodes 101-1, 101-2, and 101-N in the above are consistent and will not be described again here. External clients 321, nodes 323, and nodes 335 can communicate with each other to respond to user requests. In some embodiments, node 323 includes application (APP) 325, Pod 327, service 329, APP 331, and Pod 333, and node 335 includes Pod 337. The App, service, and Pod within node 323 can communicate with each other. The communication link can be APP 331-service 329-Pod 327, Pod 333-Pod 327, or service 329-Pod 333. The communication endpoints within node 323 can also communicate with the communication endpoints in node 325. For example, the communication link can be service 329-Pod 327. The communication links are diverse, and this disclosure does not limit them.

[0045] As mentioned above, because connections involve multiple hops and diverse forwarding paths, it is difficult to trace each hop. Tracing each hop also means adding more trace points to the eBPF program. This can impact system performance, generate a large amount of trace data, and increase computational complexity. Therefore, it is possible to trace only the first and last hops of the connection; for example, the first hop could be a client, and the last hop could be a terminal. This can be achieved through connection tracing (conntrack) supported by the operating system. In this way, Figure 3A The connection tracker 315 can track only the specified hops in the connection and create a runtime trace table 317 based on the runtime information of the specified hops. The runtime trace table 317 can quickly identify the connection and obtain the address information of the client, service and Pod for performance calculation.

[0046] Figure 3C A schematic diagram of a query table 300C including information about Pods and services, according to some embodiments of this disclosure, is shown. Figure 3C As shown, the query tables can include Pod query table 339, which is indexed by the Pod name. A Pod table, such as Pod table 341 or Pod table 343, can be retrieved by Pod name. The number of Pod tables depends on the number of Pods across multiple nodes. Pod tables can contain information such as Pod name, IP address, status, update time, node, and service name. The service name can be used as an index to retrieve service table 345. Service table 345 can include information such as service name, type, port, target Pod, and status. By combining Pod query table 339 and service table 345, Pods and services in the cluster can be efficiently queried and managed.

[0047] Figure 3DA schematic diagram of an operation tracking table 300D according to some embodiments of the present disclosure is shown. Figure 3D As shown, the runtime tracking tables may include Tables 347, 349, and 351. Table 347 includes the source IP address and destination IP address of the hops to be tracked in the connection. Table 347 can be used to determine the source IP address and destination IP address of the connection corresponding to the data packet. Table 349 includes the connection name, which can be used as an index to Table 351. Table 351 may include detailed runtime information for each entry in each connection, such as IP port, status, establishment time, reset time, shutdown time, IO data volume retry time, etc. In some embodiments, for fast lookup, the above tables can all be implemented using hash tables.

[0048] Figure 4 A flowchart of a method 400 for monitoring connection performance and diagnosing faults according to some embodiments of the present disclosure is shown. Method 400 is explained using the example of a client as the source of data packets and a Pod as the endpoint for connection performance monitoring and fault diagnosis. At block 402, data packets on the connection are read and a trace table is initialized. For example, as... Figure 3A As shown, the task controller 305 can send packet capture tasks to multiple nodes based on user requests, and the service / pod monitor 311 initializes the query table 313, while the connection tracer initializes the run trace table 317. In box 404, it is determined whether the packets have been reset. For example, as... Figure 3A As shown, the result analyzer 319 can determine whether a data packet has been reset based on the information in the received data packet. If a data packet is detected to have been reset, block 406 is executed to report the reset error and time. The result analyzer 319 can also report the reset error and reset time to the tracking agent 303.

[0049] At box 408, determine whether there is I / O data between the client and the service. For example, ... Figure 3A As shown, the result analyzer 319 can query the runtime trace table 317 to determine whether there is IO data between the client and the service. When there is no IO data between the client and the service, box 410 is executed, reporting a service unreachable error. The result analyzer 319 can also report a service unreachable error to the trace agent 303. At box 412, it is determined whether there is IO data between the service and the target. For example, as... Figure 3A As shown, when the target is a Pod, the result analyzer 319 can query the runtime trace table 317 to determine whether there is IO data between the service and the Pod. If there is no IO data between the service and the Pod, then execute box 414 to report a Pod unreachable error. The result analyzer 319 can also report the Pod unreachable error to the trace agent 303.

[0050] At box 416, determine whether the transmission should be retried. For example, as... Figure 3A As shown, the result analyzer 319 can query the runtime trace table 317 to determine whether the packet transmission was retried. When the transmission was retried, box 418 is executed to report the number of retries and the connection information of the retried packets. When the transmission was not retried, it means that the packet transmission may have failed. In this case, box 420 is executed to retrieve the Pod name and status information from the Pod table. For example, as... Figure 3A and Figure 3C As shown, the name and status information of the target Pod can be obtained by querying the Pod table in the runtime trace table 317 through the result analyzer 319.

[0051] At box 422, determine if the Pod is active. The result analyzer 319 can determine this based on the acquired Pod status information. If the Pod is active, execute box 424 to end the detection. If the Pod is inactive, execute box 426 to determine if another Pod with the same name is active. If the other Pod is active, execute box 428 to report a Pod rescheduling error. Otherwise, execute box 430 to report a Pod destruction error.

[0052] In this way, information about each captured data packet can be obtained, and the source of the problem can be located when issues arise. This allows the tracing service to provide more accurate and comprehensive performance data to assist in performance tuning and fault diagnosis.

[0053] Figure 5 A schematic diagram of a packet capture process 500 according to some embodiments of the present disclosure is shown. Figure 5 This demonstrates the packet processing and forwarding process at the IP layer. For each received packet, the IP layer needs to perform data fragmentation / reassembly or forwarding. To more accurately calculate the latency of packets from the upper layer, local delivery point 501 and local output point 503 can be used as trace points. Local delivery point 501 and local output point 503 are close to the TCP layer and contain complete packets from the upper layer that have not been fragmented / reassembled. These two trace points allow for convenient calculation of IO latency and throughput while avoiding the generation of large amounts of trace data. This approach helps to more accurately track throughput and latency in the ingress and egress directions in extended systems with lower system performance impact and fewer trace logs, meeting the requirements for fine-tuning performance in DD extended systems.

[0054] Figure 6A schematic diagram illustrating the calculation of input / output (IO) latency and throughput 600 according to some embodiments of this disclosure is shown. In DD cluster systems, IO latency and throughput are crucial performance metrics. The following explanation uses an example of a packet communication link: external / internal client 601 - service 603 - Pod 605. At 607, a packet is sent from external / internal client 601 to Pod 605, representing an ingress send; conversely, at 609, a packet is returned from Pod 605 to external / internal client 601, representing an ingress response. At 611, a packet is sent from external / internal client 601 to Pod 605, representing an egress send; conversely, at 609, a packet is returned from Pod 605 to external / internal client 601, representing an egress response.

[0055] In some embodiments, the IO latency value of the data packet ingress can be obtained by subtracting the ingress response time of the data packet from the ingress transmission time of the data packet from the external / internal client 601 to the Pod 605. Conversely, the IO latency value of the data packet egress can be obtained by subtracting the egress response time of the data packet from the egress transmission time of the data packet from the external / internal client 601 to the Pod 605.

[0056] In some embodiments, the entropy of the difference between the data size of the data packet and the latest response time of the source end minus the first data reception time of the source end can be used as the input throughput. For example, the difference between the latest response time of the external / internal client 601 and the first data reception time of the external / internal client 601 can be calculated first, and then the entropy between the data size of the data packet and the difference can be calculated to obtain the input throughput. Conversely, the entropy of the difference between the data size of the data packet and the latest response time of the target end minus the first data reception time of the target end can also be used as the output throughput. For example, the difference between the latest response time of Pod 605 and the first data reception time of Pod 605 can be calculated first, and then the entropy between the data size of the data packet and the difference can be calculated to obtain the input throughput.

[0057] Figure 7A schematic block diagram of an example device 700 that can be used to implement embodiments of the present disclosure is shown. As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) 702 or loaded from storage unit 708 into random access memory (RAM) 703. Various programs and data required for the operation of device 700 may also be stored in RAM 703. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0058] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0059] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as method 200. For example, in some embodiments, method 200 may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of method 200 described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform method 200 by any other suitable means (e.g., by means of firmware).

[0060] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload programmable logic devices (CPLDs), and so on.

[0061] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0062] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer 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 of the foregoing. Furthermore, although operations are depicted in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0063] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for monitoring connection status, comprising: Based on the received user request, a data packet capture task associated with the user request is sent to multiple nodes. Receive the captured data packets from the plurality of nodes; Determine the information of the source end, the information of the destination end, and the operational information of the connection between the source end and the destination end of the data packet; as well as The status of the connection is monitored based on at least one of the data packets, the information from the source end, the information from the target end, and the operational information.

2. The method according to claim 1, further comprising: Based on a first preset time, update a query table containing information about multiple services and multiple container groups (Pods) of the multiple nodes.

3. The method according to claim 2, wherein determining the source information of the data packet, the destination information, and the operational information of the connection between the source and the destination includes: Based on the user request, obtain the source address, destination address, and runtime information of the connection associated with the user request; Create a runtime tracking table based on the source address, the target address, and the runtime information; In response to receiving the data packet, the source address, destination address, and operation information of the connection corresponding to the data packet in the operation tracking table are determined; as well as Based on the determined source address, the destination address, and the query table, the source information and the destination information of the data packet are determined.

4. The method of claim 3, wherein the connection includes multiple hops, wherein obtaining the source address, destination address, and runtime information of the connection associated with the user request includes: Obtain the source address, destination address, and runtime information of the first and final hops of the connection.

5. The method according to claim 4, further comprising: The operation tracking table is updated based on the second preset time.

6. The method of claim 1, wherein monitoring the status of the connection comprises: Determine whether the data packet is a reset data packet; as well as In response to the packet being a reset packet, a reset error and the reset time are reported.

7. The method of claim 6, wherein monitoring the status of the connection further comprises: Based on the operational information, determine whether the connection includes input / output (IO) data; as well as In response to the connection not including the IO data, the target end is reported as unreachable.

8. The method of claim 7, wherein monitoring the status of the connection further comprises: Based on the operational information, determine whether the transmission of the data packet should be retried; as well as In response to a retry of the transmission of the data packet, the number of retries and information about the connection corresponding to the data packet are reported.

9. The method of claim 8, wherein monitoring the status of the connection further comprises: In response to the fact that the transmission of the data packet is not retried, determine whether the Pod at the target end is in an active state; as well as The monitoring is completed in response to the Pod being active on the target device.

10. The method of claim 9, wherein monitoring the status of the connection further comprises: In response to the Pod being inactive at the target end, determine whether another Pod with the same name as the Pod is active; In response to another Pod with the same name as the stated Pod being active, a Pod rescheduling error is reported; and In response to another Pod with the same name as the Pod being inactive, a Pod destruction error is reported.

11. The method of claim 1, wherein monitoring the status of the connection comprises: The I / O latency value of the data packet is determined based on the transmission time of the data packet from the source end to the target end and the response time of the data packet from the target end back to the source end.

12. The method of claim 11, wherein monitoring the status of the connection further comprises: The input throughput is determined based on the data volume of the data packet, the latest response time of the source end, and the first data reception time of the source end. as well as The output throughput is determined based on the data volume of the data packet, the latest response time of the target end, and the first data reception time of the target end.

13. The method of claim 1, wherein the data packets are captured by the plurality of nodes from local delivery points and local output points in the Internet Protocol (IP) layer.

14. An electronic device, comprising: At least one processor; as well as Coupled to the at least one processor and having instructions stored thereon, the instructions, when executed by the at least one processor, cause the electronic device to: Based on the received user request, a data packet capture task associated with the user request is sent to multiple nodes. Receive the captured data packets from the plurality of nodes; Determine the information of the source end, the information of the destination end, and the operational information of the connection between the source end and the destination end of the data packet; as well as The status of the connection is monitored based on at least one of the data packets, the information from the source end, the information from the target end, and the operational information.

15. The device of claim 14, wherein the instructions, when executed by the at least one processor, further cause the electronic device to: Based on a first preset time, update a query table containing information about multiple services and multiple container groups (Pods) of the multiple nodes.

16. The apparatus of claim 15, wherein the instructions for determining information about the source end of the data packet, information about the destination end, and operational information about the connection between the source end and the destination end include instructions for: Based on the user request, obtain the source address, destination address, and runtime information of the connection associated with the user request; Create a runtime tracking table based on the source address, the target address, and the runtime information; In response to receiving the data packet, the source address, destination address, and operation information of the connection corresponding to the data packet in the operation tracking table are determined; as well as Based on the determined source address, the destination address, and the query table, the source information and the destination information of the data packet are determined.

17. The device of claim 16, wherein the connection includes multiple hops, wherein the instructions for obtaining the source address, destination address, and operational information of the connection associated with the user request include instructions for: Obtain the source address, destination address, and runtime information of the first and final hops of the connection.

18. The device of claim 17, wherein the instructions, when executed by the at least one processor, further cause the electronic device to: The operation tracking table is updated based on the second preset time.

19. The device of claim 14, wherein the instructions for monitoring the status of the connection include instructions for: Determine whether the data packet is a reset data packet; and In response to the packet being a reset packet, a reset error and the reset time are reported.

20. A computer program product tangibly stored on a non-volatile computer-readable medium and comprising machine-executable instructions that, when executed, cause a machine to: Based on the received user request, a data packet capture task associated with the user request is sent to multiple nodes. Receive the captured data packets from the plurality of nodes; Determine the information of the source end, the information of the destination end, and the operational information of the connection between the source end and the destination end of the data packet; as well as The status of the connection is monitored based on at least one of the data packets, the information from the source end, the information from the target end, and the operational information.

Images