云原生场景下，nettrace怎么快速进行网络故障诊断？

导言｜nettrace工具自上线以来，受到了业界的广泛关注。特别是复杂的云原生网络环境中，nettrace 工具通过报文跟踪、网络诊断的方式为用户解决了多次疑难网络问题。今天就以OpenCloudOS为例，介绍在云原生场景中nettrace如何快速进行网络故障诊断。

工具简介

1）背景

在一些场景下（特别是云原生场景），Linux 系统中的网络部署变得越来越复杂。一个 TCP 连接，从客户端到服务端，中间可能要经过复杂的 NAT、GRE、IPVS 等过程，网络报文在节点（主机）上的处理路径也变得越来越长。在发生网络故障（比如网络丢包）时，如何快速、有效地定位出网络问题成为了一个难题。目前常规的网络故障定位手段，如 tcpdump、dropwatch、ftrace、kprobe 等存在一定的短板：

tcpdump：只能在链路层抓包，无法定位内核协议栈中的问题，比如常规的内核丢包问题；ftrace：只能跟踪内核函数，无法进行报文过滤，且入手较难，需要对内核协议栈有一定了解；kprobe：临时编写内核模块，效率和安全性低；BCC：功能单一，临时编写 BCC 程序跟踪效率低，需要对内核有一定了解，入手难；dropwatch：功能单一，只能查看网络丢包问题，且无法得到丢包原因和解决方案；

在此背景下，笔者结合多年的 Kernel 网络协议栈故障定位经验，基于 eBPF 开发了 Linux 环境下网络故障定位工具集——nettrace。

2）功能介绍

nettrace 是一款基于 eBPF 的集网络报文跟踪（故障定位）、网络故障诊断、网络异常监控于一体的网络工具集，旨在能够提供一种更加高效、易用的方法来解决复杂场景下的网络问题。目前，其实现的功能包括：

网络报文跟踪：跟踪网络报文从进入到内核协议栈到释放/丢弃的过程中在内核中所走过的路径，实现报文整个生命周期的监控，并采集生命周期各个阶段的事件、信息。通过观察报文在内核中的路径，对于有一定内核协议栈经验的人来说可以快速、有效地发现网络问题。

网络故障诊断：将以往的经验集成到工具的知识库，通过知识匹配的方式来主动诊断当前网络故障，给出诊断结果以及修复建议。该功能入手简单、易用性强，无需过多的网络经验即可进行网络问题定位。

网络异常监控：常态化地部署到生产环境中，主动地发现、上报环境上的网络异常。

droptrace：用于跟踪、监控系统中的丢包事件的工具，在文末链接中查看详情介绍。该功能已被遗弃，可以使用 nettrace --drop 实现相同的功能。

安装方法

nettrace 是采用 C 语言编写的基于 eBPF（libbpf）的命令行工具，在使用和安装时可以用编译好的 RPM 包和二进制程序。注意：本工具目前仅在 4.14 及以上的内核版本上进行过兼容性测试，因此请确保当前的系统所使用的的内核版本在 4.14 以上。

对于默认继承 yum 的 OpenCloudOS，本工具已经上线到对应的软件仓库，可以方便快捷地直接使用 yum 命令来进行在线安装：

其中，参数 s/d/addr/S/D/port/p/pid 用于进行报文的过滤，可以通过 IP 地址、端口、协议等属性进行过滤。其他参数的用途包括：

t/trace：要启用的跟踪模块，默认启用所有；ret：跟踪和显示内核函数的返回值；detail：显示跟踪详细信息，包括当前的进程、网口和 CPU 等信息；date：以时间格式打印（以2022-10-24xx:xx:xx.xxxxxx 格式打印），而不是时间戳；basic：启用 basic 跟踪模式。默认情况下，启用的是生命周期跟踪模式。启用该模式后，会直接打印出报文所经过的内核函数 /tracepoint；diag：启用诊断模式；diag-quiet：只显示出现存在问题的报文，不显示正常的报文；diag-keep：持续跟踪。diag 模式下，默认在跟踪到异常报文后会停止跟踪，使用该参数后，会持续跟踪下去；hooks：结合 netfilter 做的适配，详见下文；drop：进行系统丢包监控，取代原先的 droptrace；drop-stack: 打印 kfree_skb 内核函数的调用堆栈。

下面我们首先来看一下默认模式下的工具使用方法。

1）生命周期

默认情况下，nettrace会跟踪报文从进入到内核协议栈到离开（销毁）的过程。对于有一定内核网络经验的人来说，可以通过报文的内核路径来快速推断出当前的网络问题，达到快速定位的目的。

跟踪ping报文

上面的*中间的表示当前所跟踪的 skb 的地址，由于当前的报文被克隆过，因此当前跟踪上下文存在两个报文。

指定过滤条件

显示详细信息

可以看到，每个报文的地址、所在 CPU、网口和进程信息都被打印了出来。

NAT 跟踪

在对报文进行跟踪时，一旦报文被跟踪起来（命中过滤条件），那么这个报文即使内容发生了变化也会持续被跟踪，知道报文被释放。下面是 NAT 场景下的跟踪，可以看到报文的源地址由 192.168.122.8 通过 SNAT 被修改成了 9.135.224.89，但是报文依然被跟踪到了：

2）诊断模式

使用方式与上面的一致，加个 diag 参数即可使用诊断模式。上文的生命周期模式对于使用者的要求比较高，需要了解内核协议栈各个函数的用法、返回值的意义等，易用性较差。诊断模式是在生命周期模式的基础上，提供了更加丰富的信息，使得没有网络开发经验的人也可进行复杂网络问题的定位和分析。

基本用法

下面是使用诊断模式进行报文跟踪的用法，可以看出来相比于普通模式，诊断模式提供了更多的可供参考的信息，包括当前报文经过了 iptables 的哪些表和哪些链、报文发生了 NAT、报文被克隆了等。诊断模式设置了三种提示级别：第一种，INFO：正常的信息提示；第二种，WARN：警告信息，该报文可能存在一定的问题，需要关注；第三种，ERROR：异常信息，报文发生了问题（比如被丢弃）。

如果当前报文存在 ERROR，那么工具会给出一定的诊断修复建议，并终止当前诊断操作。通过添加 diag-keep 可以在发生 ERROR 事件时不退出，继续进行跟踪分析。下面是发生异常时的日志：

从这里的日志可以看出，在报文经过 iptables 的 filter 表的 forward 链的时候，发生了丢包。在诊断结果里，会列出所有的异常事件，一个报文跟踪可能会命中多条诊断结果。这里的诊断建议是让用户检查 iptables 中的规则是否存在问题。

其中kfree_skb这个跟踪点是对drop reason内核特性做了适配的，可以理解为将 droptrace 的功能集成到了这里的诊断结果中，这里可以看出其给出的对包原因是 NETFILTER_DROP。

netfilter支持

网络防火墙是网络故障、网络不同发生的重灾区，因此netfilter工具对 netfilter 提供了完美适配，包括老版本的iptables-legacy和新版本iptables-nft。诊断模式下nettrace能跟踪报文所经过的iptables表和 iptables 链，并在发生由于 iptables 导致的丢包时给出一定的提示，上面的示例充分展现出了这部分。

除了对 iptables 的支持，nettrace 对整个 netfilter 大模块也提供了支持，能够显示在经过每个 HOOK 点时对应的协议族和链的名称。除此之外，为了应对一些注册到 netfilter 中的第三方内核模块导致的丢包问题，nettrace 还可以通过添加参数 hooks 来打印出当前 HOOK 上所有的的钩子函数，从而深入分析问题：

可以看出，上面 following hook functions are blamed 中列出了导致当前 netfilter 丢包的所有的钩子函数，这里只有 iptables 一个钩子函数。

其他场景

由于对drop reason 内核特性进行了适配，因此对于支持 drop reason 的系统，基于 drop reason 本工具可以诊断 70+ 种丢包问题。nettrace 通过将网络诊断经验翻译成规则存储到规则库的方式来进行诊断分析，通过扩充规则配置文件的方式能够不断增强其诊断功能。目前，本工具已经集成了 20+ 典型网络故障诊断功能，并且在实践中不断完善知识库（规则库）。

端口未监听导致的丢包：

XDP 导致的丢包：

3）丢包监控

使用命令 nettrace --drop 可以对系统中的丢包事件进行监控，对于支持内核特性 skb drop reason 的内核，这里还会打印出丢包原因。可以通过查看 /tracing/events/skb/kfree_skb/format 来判断当前系统是否支持该特性：

该模式下使用的效果与原先的 droptrace 完全相同，如下所示：

同样可以使用 man dropreason 命令来查看对应的丢包原因的详细解释。对于不支持 skb drop reason 特性的内核，该模式下将不会打印丢包原因字段，效果如下所示：