一种基于eBPF的内核丢包检测方法、系统和装置与流程

一种基于ebpf的内核丢包检测方法、系统和装置
技术领域
1.本发明涉及计算机技术领域，具体涉及一种基于ebpf的内核丢包检测方法、系统和装置。


背景技术：

2.数据在网络中是被分成一个个数据包传输的，每个数据包中有表示数据信息和提供数据路由的帧。而数据包在一般介质中传播是总有一小部分由于各种各样的原因而丢失，而大部分数据包会到达目的终端。网络丢包率是数据包丢失部分与所传数据包总数的比值。正常传输时，网络丢包率应该控制在一定范围内。在数据中心中，网络的运维是对业务运维中的重要一环，只有保证了网络的平稳运行，业务才能平稳运行，网络运维中很重要的一个指标就是丢包率，如果丢包率很高，业务正常执行的延时就会大很多，甚至出现业务异常，因此丢包检测对于数据中心的意义非常重要。
3.目前网络运维中为了得到网络丢包率主要有两种方式：第一种方式称之为交换机镜像，在交换机或路由器上通过端口镜像功能，将一个或多个源端口的数据流量转发到某一个指定端口来实现对网络的监听；第二种方式称之为主机抓包分析，通过tcpdump将主机所有经过的网络流量抓取形成pcaap文件，之后利用类似wi reshark工具进行分析。不管是是交换机镜像模式，还是主机抓包分析模式，网络丢包分析的本质都是获取tcp的流量，之后根据tcp原理，分析tcp数据包的情况，从而判断出是否丢包。因此抓取的数据量和分析的数据量较大。
4.例如，交换机镜像模式下，需要在交换机层面做镜像分光，需要有单独的存储所有的网络包，之后有大性能的机器进行分析。由于数据中心的规模都不小，每天的流量都可以达到tb级别，端口镜像实施成本都在几百万至数千万级别。同时交换机镜像模式不适用于云环境，因为虚拟云网络通讯的时候，很多流量不通过交换机，比如两台部署在同一台物理机的虚拟机进行网络通信就不经过交换机。主机抓包分析模式虽然成本比端口镜像省了很大的存储成本，但是其实时性不足，只能在有问题之后，作为事后排查问题的手段；同时如果长期开启该模式，对处理器和本地磁盘存储的要求很大，在生产环境中都是事后开启。


技术实现要素：

5.针对现有技术中存在的上述技术问题，本发明提供一种基于ebpf的内核丢包检测方法、系统和装置，仅抓取丢包数据，数据处理量少。
6.本发明公开了一种基于ebpf的内核丢包检测方法，所述内核丢包检测方法包括：基于ebpf，在内核函数tcp_drop前进行插桩；通过插桩的函数，从寄存器中抓取内核函数tcp_drop的丢包数据，并将所述丢包数据存入ebpf map中；在用户态中，读取所述ebpf map中的丢包数据；将所读取的丢包数据匹配相应的虚拟机、进程或容器，获取匹配数据。
7.优选的，抓取内核函数tcp_drop的丢包数据的方法包括：
8.在函数tcp_drop执行前，从内核数据结构pt_reges中拦截丢包数据。
9.优选的，所述函数tcp_drop的参数包括sk和skb；
10.从内核数据结构pt_regs的第一个入参中读取sk参数的值；
11.从内核数据结构pt_regs的第二个入参中读取skb参数的值。
12.优选的，插桩的函数包括hook函数，通过hook函数抓取函数tcp_drop的丢包数据，并将所述丢包数据保存在ebpf map中。
13.优选的，将所述丢包数据转换为event结构数据后，保存在ebpf map中；
14.在用户态中，从所述ebpf map中所读取的丢包数据包括：tcp连接的状态和sk_buff；
15.所述sk_buff包括以下任一信息或它们的组合：tcp四元组、网卡名称和mac地址。
16.优选的，本发明的内核丢包检测方法，还包括从sk_buff中解析数据的方法：
17.根据sk_buff的head地址和mac_head地址偏移量计算ethhdr地址，在ethhdr数据结构中获取mac地址；
18.根据sk_buff的head地址和network_header地址偏移量计算iphdr地址,在ipdhdr数据结构中获取ip地址；
19.根据协议转化数据结构，tcp转化为tcphdr，ipip的端口为0，udp为udphdr，再从所转化的数据结构中获取srcport和dstprot端口。
20.优选的，将所读取的丢包数据匹配相应的虚拟机或进程的方法包括：
21.从系统文件中获取ip、端口列表，以及进程列表；
22.将所述tcp四元组与所述ip、端口列表进行匹配，获得关联虚拟机的信息；
23.将所述tcp四元组与所述进程列表匹配，获得关联进程的信息；
24.将所读取的丢包数据匹配容器的方法包括：
25.根据所述tcp四元组中的容器id或网卡名称，匹配相应的容器。
26.优选的，基于ebpf的kprobe探针的方法在内核函数tcp_drop中进行插桩。
27.本发明还提供一种用于实现上述内核丢包检测方法的系统，包括：插桩模块、拦截模块、拷贝模块和匹配模块；
28.所述插桩模块用于基于ebpf，在内核函数tcp_drop前进行插桩；
29.所述拦截模块用于通过插桩的函数，从寄存器抓取内核函数tcp_drop的丢包数据，并将所述丢包数据存入ebpf map中；
30.所述拷贝模块用于在用户态中，读取所述ebpf map中的丢包数据；
31.所述匹配模块用于将所读取的丢包数据匹配相应的虚拟机、进程或容器，获取匹配数据。
32.本发明还提供一种装置，包括存储器和处理器，所述存储器用于保存程序，所述程序包括用于实现上述内核丢包检测方法的指令；
33.所述处理器用于执行所述程序。
34.与现有技术相比，本发明的有益效果为：通过插桩的方法，在寄存器中抓取内核函数的丢包数据，保存在ebpf map中，在用户态下，可以读取到ebpf map中的丢包数据；数据在丢包时才会调用tcp_drop，因此仅采集了丢包数据，而不会采集其它的正常数据或非丢包数据，利于减少计算或数据体量，同时不会对内核网络包路径造成影响；匹配数据利于提高数据的可读性。
附图说明
35.图1是本发明的基于ebpf的内核丢包检测方法的流程图；
36.图2是本发明的系统逻辑框图；
37.图3是实施例的逻辑框图。
具体实施方式
38.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。
39.下面结合附图对本发明做进一步的详细描述：
40.一种基于ebpf的内核丢包检测方法，如图1所示，所述内核丢包检测方法包括：
41.步骤101：基于ebpf，在内核函数tcp_drop前进行插桩。
42.在一个具体实施例中，基于ebpf的kprobe探针的方法在内核函数tcp_drop前进行插桩，kprobe探针为现有技术，本发明中不再赘述。内核触发丢包时，会执行函数tcp_drop，其函数结构为：void tcp_drop(struct sock*sk,struct sk_buff*skb)，其中，sk为第一参数，skb为第二参数。sk_buff是linux网络代码中最重要的结构体之一，是linux在其协议栈里传送的结构体，也就是所谓的“包”，数据结构里包含了各层协议的头部。
43.步骤102：通过插桩的函数，抓取内核函数tcp_drop的丢包数据，并将所述丢包数据保存在ebpf map中。ebpf map是以键/值方式存储在内核中的数据结构，可以被ebpf程序访问，通常设置在环形缓冲区或循环缓冲区中(ring buffer)。插桩的函数可以是hook函数。
44.步骤103：在用户态中，读取所述ebpf map中的丢包数据。
45.步骤104：将所读取的丢包数据匹配相应的虚拟机、进程或容器，获取匹配数据。
46.通过插桩的方法，在寄存器中抓取内核函数的丢包数据，通过保存在ebpf map中，在用户态下，可以读取到ebpf map中的丢包数据；数据在丢包时才会调用tcp_drop，因此仅采集了丢包数据，而不会采集其它的正常数据或非丢包数据，利于减少计算或数据体量，同时不会对内核网络包路径造成影响；匹配数据利于提高数据的可读性。
47.步骤102中，抓取内核函数tcp_drop的丢包数据的方法包括：
48.在函数tcp_drop执行前，从内核数据结构pt_regs中拦截丢包数据。在内核执行丢包处理函数以前，即可以检测到丢包，提高实时性高。
49.在函数执行前拦截的函数，其内核数据结构pt_regs的入参具有如下对应关系:
[0050][0051]
其中，sk为函数的第一个参数，可以从第一个入参(di)中读取相关内容，skb为该函数的第二个参数，可以从第二个入参(si)中读取相关内容。
[0052]
其中，可以通过hook函数从函数tcp_drop的内核数据结构pt_regs中抓取丢包数据，并将所述丢包数据保存在ebpf map中。
[0053]
其中，可以将所述丢包数据转换为event结构数据后，保存在ebpf map中。
[0054]
步骤103中，在用户态下，从所述ebpf map中所读取的丢包数据包括：tcp连接的状态(state)和sk_buff。所述sk_buff包括以下任一信息或它们的组合：tcp四元组、网卡名称和mac地址。
[0055]
从所述ebpf map中，仅读取少量的数据结构，具体的，每次读取50个字节以内的数量，因此，拷贝量少，资源消耗小。
[0056]
其中，从ebpf map中读取数据时，还包括从ebpf map的sk_buff中解析数据的方法：
[0057]
根据sk_buff的head地址和mac_head地址偏移量计算ethhdr地址，在ethhdr数据结构中获取mac地址；
[0058]
根据sk_buff的head地址和network_header地址偏移量计算iphdr地址,在ipdhdr数据结构中获取ip地址；
[0059]
根据协议转化数据结构，tcp转化为tcphdr，ipip的端口为0，udp为udphdr，再从所转化的数据结构中获取srcport和dstprot端口。
[0060]
步骤104中，将所读取的丢包数据匹配相应的虚拟机或进程的方法包括：
[0061]
从系统文件中获取ip、端口列表，以及进程列表，例如从/proc/pid/tcp(udp)文件中读取对应ip 端口的列表，从/proc/pid/comm文件读取进程名称；
[0062]
将所述tcp四元组与所述ip、端口列表进行匹配，获得关联虚拟机的信息；
[0063]
将所述tcp四元组与所述进程列表匹配，例如根据进程id(pid)进行匹配，获得关联进程的信息。
[0064]
步骤104中，将所读取的丢包数据匹配容器的方法包括：
[0065]
根据所述tcp四元组中的容器id或网卡名称，匹配相应的容器。
[0066]
例如，若网卡为容器网卡eth0，则skb中的四元组为podip，根据podip匹配到具体容器；若网卡为cni网卡，则根据网卡名称匹配到具体容器。在一个具体实施例中，该检测方式以daemonset(服务守护进程)形式部署在kubernetes集群中，采用incluster模式的方式鉴权，获取容器信息。一般而言，在kubernetes中进行rpc调用，会采用service方式，该关联数据级别是service层面的，通过conntrack进行关联，可以匹配到调用了具体哪个pod。连
接跟踪(connection tracking，conntrack，ct)用于跟踪(并记录)连接的状态；用于完成连接信息的采集和录入功能。关联规则如下，将conntrack信息以nat前的tcp四元组为key，nat后的四元组为value存入ebpfmap，根据抓取到tcp四元组为key进行查询。因此，将不易读懂的tcp四元组信息关联到易读懂的具体应用名称，从而提高匹配信息的易读性。
[0067]
本发明还可以包括匹配数据输出的步骤，例如将丢包数据或及匹配数据输出为日志。例如，在传统虚机环境下，输出发生丢包的进程名称和四元组、mac地址；在云上环境下,输出发生丢包对应四元组的容器信息和丢包发生的网卡。
[0068]
本发明还提供一种用于实现上述内核丢包检测方法的系统，如图2所示，包括：插桩模块1、拦截模块2、拷贝模块3和匹配模块4；
[0069]
插桩模块1用于基于ebpf，在内核函数tcp_drop前进行插桩；
[0070]
拦截模块2用于通过插桩的函数，从寄存器中抓取内核函数tcp_drop的丢包数据，并将所述丢包数据存入ebpf map11中；
[0071]
拷贝模块3用于在用户态中，读取所述ebpf map11的丢包数据；
[0072]
匹配模块4用于将所读取的丢包数据匹配相应的虚拟机、进程或容器，获取匹配数据。本发明的系统还包括输出模块5，所述输出模块用于根据所述匹配数据，输出日志。
[0073]
实施例
[0074]
根据上述内核丢包检测方法，构建如下场景：demo部署环境为kubernetes环境，部署在第一节点(node1)的testdemo1持续向部署在第二节点(node2)的testdemo2发出http请求，即数据请求。
[0075]
在kubernetes的第一节点中部署上述系统，用于执行内核丢包检测方法。具体的，如图3所示，插桩模块1调用bpf()函数在内核中注入kprobe探针；其中，部署在ebpf虚拟机的拦截模块2通过kprobe探针的hook函数拦截tcp_drop函数的丢包数据，解析出丢包数据结构sk_buff和sock中的关键内容，并将关键内容转换为event结构数据后，保存在环形缓冲区(ring buffer)中；拷贝模块3从环形缓冲区中读取event结构数据(即丢包数据)；匹配模块4根据所读取的event结构数据与线程数据或容器数据进行关联和匹配。其中，线程数据可以从相关目录中的列表数据中获取；容器数据可以从kubernetes系统中获取。
[0076]
使用linux提供的tc工具在第一节点中开启随机丢包，将丢包率设计为1％。
[0077]
上述系统输出的日志如下：
[0078]
drop time
[0079]
aug 23 10:42:35cst 2021
[0080]
drop info:
[0081]
‑
>src_containerid:string(59fa75f0e8f5)
[0082]
‑
>src_container:string(testdemo1)
[0083]
‑
>src_node:string(kubernetes node2)
[0084]
‑
>src_namespace:string(hcmine)
[0085]
‑
>src_workload_kind:string(deployment)
[0086]
‑
>src_workload_name:string(testdemo1)
[0087]
‑
>src_pod:string(testdemo1
‑
78b7759f78
‑
nxwr8)
[0088]
‑
>src_pod_ip:string(192.168.40.208)
[0089]
‑
>src_service:string(testdemo1)
[0090]
‑
>src_service_ip:string(10.103.33.148)
[0091]
‑
>src_mac:string(00:50:56:92:7a:4d)
[0092]
‑
>dst_namespace:string(hcmine)
[0093]
‑
>dst_service:string(testdemo2)
[0094]
‑
>dst_service_ip:string(10.111.214.178)
[0095]
‑
>dst_service_port:int(9001)
[0096]
‑
>dst_containerid:string()
[0097]
‑
>dst_container:string(testdemo2)
[0098]
‑
>dst_node:string(kubernetes node1)
[0099]
‑
>dst_namespace:string(hcmine)
[0100]
‑
>dst_workload_kind:string(deployment)
[0101]
‑
>dst_workload_name:string(testdemo2)
[0102]
‑
>dst_pod:string(testdemo2
‑
7d75b8886
‑
x6fwv)
[0103]
‑
>dst_pod_ip:string(192.168.106.187)
[0104]
‑
>dst_service:string(testdemo2)
[0105]
‑
>dst_service_ip:string(10.111.214.178)
[0106]
‑
>dst_mac:string(00:50:56:92:ca:7e)
[0107]
‑
>drop_dev:string(ens192)
[0108]
‑
>is_server:bool(false)
[0109]
因此，本发明的系统可以很好的匹配到容器(pod)丢包的信息、节点信息、以及服务等信息等。
[0110]
本发明还提供一种装置，包括存储器和处理器，所述存储器用于保存程序，所述程序包括用于实现上述内核丢包检测方法的指令；所述处理器用于执行所述程序。
[0111]
以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。