CN114205218B - 一种容器网络故障的诊断方法和系统 - Google Patents

Abstract

本发明公开了一种容器网络故障的诊断方法和系统，所述诊断方法包括：基于eBPF的方法，获得容器网卡的收发事件，所述收发事件包括收包事件和发包事件；获得执行系统的网络类系统调用事件，所述网络类系统调用事件包括Socket类型事件，所述socket类型事件包括请求发起事件和请求接收事件；获取socket类型事件的四元组信息；为所述请求发起事件匹配相应的请求接收事件，获得请求数据及其执行时间；根据所述四元组信息，为所述收发事件匹配相应的请求数据；根据所述收发事件相应的执行时间，诊断所述容器的网络故障。请求数据反映了收发事件的执行情况，根据所述执行情况和收发事件的对容器的网络故障进行诊断，跟踪数据包在内核栈中的流转，利于全面分析容器的网络情况。

Description

一种容器网络故障的诊断方法和系统

技术领域

本发明涉及计算机技术领域，具体涉及一种容器网络故障的诊断方法和系统。

背景技术

在容器网络环境中，容器使用虚拟网卡并进行跨网络命名空间通信，其采用复杂的Overlay网络。这种方案能够在将容器的网络隔离，使得底层物理设备变得透明，在获得便利的同时也引入了复杂度，因此一旦出现网络问题，排障过程就会非常复杂，特别是当问题不稳定复现时。这类问题可能会导致排障过程耗时很长，继而影响到业务的正常运行。因此，如果能够快速有效的定位容器网络问题并揭示底层根因，将降低故障恢复时间、保障业务的正常运行。

现有技术中，在遇到容器网络问题时，要首先检查问题主机上的各项网络配置，例如网卡、网桥、网络命名空间、防火墙规则，然后用抓包工具(例如tcpdump)对问题容器进行抓包，再对抓包结果做人工分析，分析其中是否存在握手失败、包重传、丢包等问题。诊断效率低、在长时间开启抓包工具时，对系统资源造成较大的压力。

发明内容

针对现有技术中存在的技术问题，本发明提供一种容器网络故障的诊断方法和系统，基于eBPF的方法，拦截网络的收发事件和执行的请求数据，利于挖掘出容器网络故障的深层问题。

本发明公开了一种容器网络故障的诊断方法，所述诊断方法包括：基于eBPF的方法，获得容器网卡的收发事件，所述收发事件包括收包事件和发包事件；基于eBPF的方法，获得执行系统的网络类系统调用事件，所述网络类系统调用事件包括Socket类型事件，所述socket类型事件包括请求发起事件和请求接收事件；获取socket类型事件的四元组信息；为所述请求发起事件匹配相应的请求接收事件，获得请求数据及其执行时间；根据所述四元组信息，为所述收发事件匹配相应的请求数据；根据所述收发事件相应的执行时间，诊断所述容器的网络故障。

优选的，所述收包事件和发包事件包括skb结构体的信息，所述skb结构体包括四元组信息。

优选的，通过eBPF探针，对net_dev_start_xmit或hard_start_xmit函数进行插桩，获得发包事件；

对netif_receive_skb进行插桩，获得收包事件；

为所述收包事件匹配相应的发包事件,获得收发事件；

对sys_enter进行插桩，获得执行系统调用事件，对所述执行系统调用事件进行筛选，获得网络类系统调用事件；对所述网络类系统调用事件进行筛选，获得socket类型事件。

优选的，所述请求发起事件包括以下任一事件或它们的组合：Write、writev、pwrite、pwritev、send、sendto和sendmsg；

所述请求接收事件包括以下任一事件或它们的组合：read、readv、pread、preadv、recv、recvfrom和recvmsg。

优选的，为所述请求发起事件匹配相应请求接收事件的方法包括：获取请求发起事件的第一时间；判断在第一域值时间内是否获得下一请求接收事件；若是，将所述请求发起事件与该请求接收事件相匹配，第一时间到下一请求接收事件的第二时间作为请求时间段；若否，将第一时间到第一域值时间作为请求时间段。

优选的，为所述收发事件匹配相应请求数据的方法包括：

判断收发事件的IP头部是否发生修改；

若是，获取收发事件的四元组信息的SKB内存地址，获得SKB内存地址数组；

根据四元组信息和SKB内存地址数组，将请求数据与收发事件进行匹配；

若否，将请求数据的四元组信息与收发事件的四元组信息进行匹配；

判断匹配到的收发事件与相应请求数据在时间上是否相符；

若相符，匹配成功；

若不相符，丢弃所述收发事件或请求数据。

优选的，通过哈希表进行匹配的方法包括：根据收发事件的四元组信息及其SKB内存地址的数组建立第一哈希表；根据收发事件的SKB内存地址和数组建立第二哈希表；将所述请求数据的四元组信息，在第一哈希表中匹配数组；使用所匹配数组的每个值在第二哈希表中匹配收发事件。

优选的，诊断所述容器的网络故障方法包括：

若收发事件的执行时间超过第二域值，判断为异常请求，所述执行时间为请求时间段的两端时间之差。

本发明还提供一种用于实现上述诊断方法的系统，包括第一拦截模块、第二拦截模块、查询模块、第二匹配模块、第三匹配模块和诊断模块，

所述第一拦截模块用于基于eBPF的方法，获得容器网卡的收发事件，所述收发事件包括收包事件和发包事件；

第二拦截模块用于基于eBPF的方法，获得执行系统的网络类系统调用事件，所述网络类系统调用事件包括Socket类型事件，所述socket类型事件包括请求发起事件和请求接收事件；

查询模块用于获取socket类型事件的四元组信息；

第二匹配模块用于为所述请求发起事件匹配相应的请求接收事件，获得请求数据及其执行时间；

第三匹配模块用于根据所述四元组信息，为所述收发事件匹配相应的请求数据；

诊断模块用于根据所述收发事件相应的执行时间，诊断所述容器的网络故障。

优选的，所述系统还包括第一匹配模块，

所述第一匹配模块用于为所述发包事件匹配相应的收包事件；

所述第二拦截模块用于对sys_enter进行插桩，获得执行系统调用事件，对所述执行系统调用事件进行筛选，获得网络类系统调用事件，对所述网络类系统调用事件进行筛选，获得socket类型事件；

所述诊断模块用于根据收发事件相应的执行时间与第二域值的关系，诊断容器的网络故障。

与现有技术相比，本发明的有益效果为：请求数据反映了收发事件的执行情况，根据所述执行情况和收发事件的对容器的网络故障进行诊断，跟踪数据包在内核栈中的流转，利于全面分析容器的网络情况；执行时间异常时，反应了容器内的执行系统的故障，收发事件的时间异常反应了网络上的故障。

附图说明

图1是本发明的容器网络故障的诊断方法流程图；

图2是收发事件和请求数据的匹配方法流程图；

图3是本发明的系统框图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

下面结合附图对本发明做进一步的详细描述：

一种容器网络故障的诊断方法，如图1所示，所述诊断方法包括：

步骤101：基于eBPF的方法，获得容器网卡的收发事件，所述收发事件包括收包事件和发包事件。收发事件反应了容器虚拟网卡的接收和发送的信息。

在一个具体实施例中，通过eBPF探针，对net_dev_start_xmit或hard_start_xmit函数进行插桩，获得发包事件；对netif_receive_skb进行插桩，获得收包事件；为所述收包事件匹配相应的发包事件，获得收发事件。收发事件的包括skb结构体的内存地址(skb内存地址)，通过skb结构体可以获得网卡名、网络命名空间、四元组信息(源IP地址、源端口、目的IP地址和目的端口)。

步骤102：基于eBPF的方法，获得执行系统的网络类系统调用事件，所述网络类系统调用事件包括Socket类型事件，所述socket类型事件包括请求发起事件和请求接收事件。

例如，对sys_enter进行插桩，获得执行系统调用事件，对所述执行系统调用事件进行筛选，获得网络类系统调用事件；对所述网络类系统调用事件进行筛选，获得socket类型事件。可以对这些事件进行时间排序。收包事件反映了客户端的请求，响应于收包事件，请求发起事件反映了开始执行请求；请求接收事件反映了结束执行请求，发包事件反映了执行结果。

步骤103：获取socket类型事件的四元组信息。具体的，Socket类型事件的结构包括：系统调用名、执行进程ID、文件描述符(FD)、时间戳和网络四元组。可以按照进程ID和文件描述符进行分组，在系统目录“/proc/”下使用进程ID和文件描述符查询得到文件描述符的类型，丢弃其中不是socket类型的事件，对于是socket类型的事件，从系统中获取到对应的socket的四元组信息

步骤104：为所述请求发起事件匹配相应的请求接收事件，获得请求数据及其执行时间。即请求数据包括请求发起事件及其相应的请求接收事件，执行开始时间到执行结束时间的时间段为执行时间，可以在系统目录中找到请求数据的四元组信息。

步骤105：根据所述四元组信息，为所述收发事件匹配相应的请求数据。

步骤106：根据所述收发事件相应的执行时间，诊断所述容器的网络故障。

请求数据反映了收发事件的执行情况，根据所述执行情况和收发事件的对容器的网络故障进行诊断，跟踪数据包在内核栈中的流转，利于全面分析容器的网络情况；执行时间异常时，反应了容器内的执行系统的故障，收发事件的时间异常反应了网络上的故障。

例如，执行时间超过第二域值，如500ms，判断为异常请求，具体为执行系统异常，所述执行时间为请求时间段的两端时间之差，即请求接收时间和请求发起时间的时间差。

步骤102中，请求发起事件可以根据以下事件进行判断：写入(Write)，写入多个非连续缓冲区(writev)，带偏移量地写数据(pwrite)，带偏移量地写入多个非连续缓冲区(pwritev)，发送数据(send)，指定目的地发送数据(sendto)和通过套接口发送数据(sendmsg)；请求接收事件可以根据以下事件进行判断：读取(read)，将读入的数据按同样顺序散布读到缓冲区中(readv)，带偏移量地读取数据(pread)，带偏移量地读取数据、并按同样顺序散布读到缓冲区中(preadv)，接收数据(recv)，从已连接的套接口上接收数据、并捕获数据发送源的地址(recvfrom)和通过套接口接收数据(recvmsg)。这些事件中包含了执行系统调用的进程ID和系统调用操作的文件描述符信息。

步骤104中，为所述请求发起事件匹配相应请求接收事件的方法包括：

步骤201：获取请求发起事件的第一时间t1。

步骤202：判断在第一域值时间内是否获得下一请求接收事件。

若是，执行步骤203：将所述请求发起事件与该请求接收事件相匹配，第一时间t1到下一请求接收事件的第二时间t2作为请求时间段。

若否，步骤204：将第一时间t1到第一域值时间(t1+w1)作为请求时间段。其中，w1可以取值2-5秒,请求时间段可以表示为t1到(t1+w1)之间的时间段，请求时间段的两端时间之差w1反映了执行时间。

步骤105中，如图2所示，为所述收发事件匹配相应请求数据的方法包括：

步骤301：判断收发事件的IP头部是否发生修改。如网络方案为macvlan等二层网络underlay或Calico的BGP等三层网络underlay，其数据包在网卡中传递时不会修改IP头部；网络方案为Calico的IPIP模式或Flannel的VXLAN模式或Flannel的UDP模式，其数据包在网卡中传递时会修改IP头部，导致请求中的不同数据包的四元组不同。

若是，执行步骤302：获取收发事件的四元组信息的SKB内存地址，获得SKB内存地址数组，执行步骤303。其中，SKB内存地址指向了存储网络包的SKB结构体；由于一次请求可能会使用多个SKB结构体传输，因此通过四元组信息可以找到多个网络包事件，即多个SKB内存地址，构成SKB内存地址数组。

步骤303：根据所述SKB内存地址数组，将请求数据与收发事件匹配，执行步骤305。虽然数据包的四元组会发生变化，但一般数据包在修改IP头部前后会复用同一个SKB内存地址，因此可以得到四元组不同但SKB内存地址相同的“收”和“发”事件，这意味着同一个SKB内存地址可能对应多个事件。若匹配到SKB内存地址在一个数组中，将该数组中的每个SKB内存地址与收发事件的SKB内存地址相匹配，即遍历SKB内存地址数组的每一个地址；若有匹配到，且在时间上相符时，则匹配成功。应当指出，请求数据中，可能存在缺失请求接收事件的情况。

若否，步骤304：将请求数据的四元组信息与收发事件的四元组信息进行匹配，执行步骤305。即请求数据与收发事件具有相同的四元组信息。

步骤305：判断匹配到的收发事件与相应请求数据在时间上是否相符。例如，请求时间段落入收发事件的时间段内，则相符，但不限于此。

若相符，步骤306：匹配成功。

若不相符，步骤307：丢弃所述收发事件或请求数据。

在一个具体实施例中，通过哈希表进行匹配：

步骤302中，根据收发事件的四元组信息及其SKB内存地址的数组建立第一哈希表；

根据收发事件的SKB内存地址和收发事件的数组建立第二哈希表；

根据所述请求数据的四元组信息，在第一哈希表中匹配SKB内存地址数组。

步骤303中，使用所匹配SKB内存地址数组的每个值在第二哈希表中匹配收发事件。即将请求数据的四元组信息相关每一个SKB内存地址与收发事件的SKB内存地址相匹配。

本申请还提供一种用于实现上述诊断方法的系统，如图3所示，包括第一拦截模块1、第二拦截模块2、查询模块3、第二匹配模块4、第三匹配模块5和诊断模块6，

第一拦截模块1用于基于eBPF的方法，获得容器网卡的收发事件，所述收发事件包括收包事件和发包事件；

第二拦截模块2用于基于eBPF的方法，获得执行系统的网络类系统调用事件，所述网络类系统调用事件包括Socket类型事件，所述socket类型事件包括请求发起事件和请求接收事件；

查询模块3用于获取socket类型事件的四元组信息；

第二匹配模块4用于为所述请求发起事件匹配相应的请求接收事件，获得请求数据及其执行时间；

第三匹配模块5用于根据所述四元组信息，为所述收发事件匹配相应的请求数据；

诊断模块6用于根据所述收发事件相应的执行时间，诊断所述容器的网络故障。

本发明的系统还可以包括第一匹配模块11，用于为所述发包事件匹配相应的收包事件。第二拦截模块2用于对sys_enter进行插桩，获得执行系统调用事件，对所述执行系统调用事件进行筛选，获得网络类系统调用事件，对所述网络类系统调用事件进行筛选，获得socket类型事件；诊断模块6用于根据收发事件相应的执行时间与第二域值的关系，诊断容器的网络故障。

以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (7)

1.一种容器网络故障的诊断方法，其特征在于，所述诊断方法包括：

通过eBPF探针，对net_dev_start_xmit或hard_start_xmit函数进行插桩，获得发包事件；对netif_receive_skb进行插桩，获得收包事件；为所述收包事件匹配相应的发包事件,获得收发事件；

对sys_enter进行插桩，获得执行系统调用事件，对所述执行系统调用事件进行筛选，获得网络类系统调用事件；对所述网络类系统调用事件进行筛选，获得socket类型事件，所述socket类型事件包括请求发起事件和请求接收事件；

获取socket类型事件的四元组信息；

为所述请求发起事件匹配相应的请求接收事件，获得请求数据及其执行时间；

根据所述四元组信息，为所述收发事件匹配相应的请求数据；

若收发事件的执行时间超过第二域值，判断为异常请求，所述执行时间为请求时间段的两端时间之差。

2.根据权利要求1所述的诊断方法，其特征在于，所述收包事件和发包事件包括SKB结构体的信息，

所述SKB结构体包括四元组信息。

3.根据权利要求1所述的诊断方法，其特征在于，所述请求发起事件包括以下任一事件或它们的组合：

Write、writev、pwrite、pwritev、send、sendto和sendmsg；

所述请求接收事件包括以下任一事件或它们的组合：

read、readv、pread、preadv、recv、recvfrom和recvmsg。

4.根据权利要求1所述的诊断方法，其特征在于，为所述请求发起事件匹配相应请求接收事件的方法包括：

获取请求发起事件的第一时间；

判断在第一域值时间内是否获得下一请求接收事件；

若是，将所述请求发起事件与该请求接收事件相匹配，第一时间到下一请求接收事件的第二时间作为请求时间段；

若否，将第一时间到第一域值时间作为请求时间段。

5.根据权利要求4所述的诊断方法，其特征在于，为所述收发事件匹配相应请求数据的方法包括：

判断收发事件的IP头部是否发生修改；

若是，获取收发事件的四元组信息的SKB内存地址，获得SKB内存地址数组；

根据四元组信息和SKB内存地址数组，将请求数据与收发事件进行匹配；

若否，将请求数据的四元组信息与收发事件的四元组信息进行匹配；

判断匹配到的收发事件与相应请求数据在时间上是否相符；

若相符，匹配成功；

若不相符，丢弃所述收发事件或请求数据。

6.根据权利要求5所述的诊断方法，其特征在于，通过哈希表进行匹配的方法包括：

根据收发事件的四元组信息及其SKB内存地址的数组建立第一哈希表；

根据收发事件的SKB内存地址和数组建立第二哈希表；

根据所述请求数据的四元组信息，在第一哈希表中匹配数组；

使用所匹配数组的每个值在第二哈希表中匹配收发事件。

7.一种用于实现如权利要求1-6任一项所述诊断方法的系统，其特征在于，包括第一拦截模块、第二拦截模块、查询模块、第二匹配模块、第三匹配模块和诊断模块，

所述第一拦截模块用于通过eBPF探针，对net_dev_start_xmit或hard_start_xmit函数进行插桩，获得发包事件；对netif_receive_skb进行插桩，获得收包事件；为所述收包事件匹配相应的发包事件,获得收发事件；

第二拦截模块用于对sys_enter进行插桩，获得执行系统调用事件，对所述执行系统调用事件进行筛选，获得网络类系统调用事件；对所述网络类系统调用事件进行筛选，获得socket类型事件；

查询模块用于获取socket类型事件的四元组信息；

第二匹配模块用于为所述请求发起事件匹配相应的请求接收事件，获得请求数据及其执行时间；

第三匹配模块用于根据所述四元组信息，为所述收发事件匹配相应的请求数据；

诊断模块用于在收发事件的执行时间超过第二域值时，判断为异常请求。