LWN: kernel developer怎样利用BPF来观测系统？

The state of system observability with BPF

By  Jonathan Corbet,  May 1, 2019,  LSFMM

题图：  Photo by  rawpixel.com  from  Pexels

译者评：Gregg真是一位非常有煽动力的老兄啊～

在2019 Linux Storage, Filessytem, and Memory-Management Summit开场有一个主议题就是Brendan Gregg介绍的Linux system BPF应用。他认为，基于BPF的众多“superpower”加入kernel后，也更加稳定成熟了，这非常令人激动。现在可以开始讨论在 Linux 商用环境里（production Linux system）如何不修改kernel来利用BFP的能力了。

Gregg首先演示了一个他刚刚写出来的小工具，能够发出一个刺耳的高频声，并且随着他在会场里走来走去而变化频率。这个小 工具 就是利用BPF实现的，提取laptop的kernel里的WiFi信息，然后据此生成高频声音播放出来。随着他用身体遮挡干扰信号强度，高频声也会随之变化。如果laptop连接到他的手机的WIFI hotspot，他就能利用这个机制来检测他的笔记本距离手机的距离。很有意思，虽然这不是一个真正商用应用，但是非常好的展示了BPF怎样能用来实现一些此前不容易做到的功能。

Gregg在Netflix工作，Netflix一般有150,000台server同时在运行，因此Netflix就很关心系统的performance，他们永远渴求能有更好的监控工具帮忙查出performance问题的来源。不过，好工具的价值不仅仅是帮助performance tuning。

Better bug reports

例如，Netflix正在试着迁移它的server kernel到4.15版本，然后马上碰到了一个问题。他们有一个log-rotation service（循环日志服务），会一直执行ps来等某个进程退出。这个工作看起来很简单直观，但是在新版本Linux kernel上就是会出错：ps会把一个仍在运行的process也判定为exit了。这个问题就需要仔细调查一下了。

Gregg先祭出了bpftrace工具（很快各大Linux发行版都会包含），满心期待能看到system call是在哪里出了问题的。针对性的，他就准备了下面的命令调用：

    bpftrace -e 't:syscalls:sys_exit_* /comm == "ps"/ \
    	     { @[probe, args->ret > 0 ? 0 : - args->ret] = count(); }'

Gregg在现场演示了很多代码，篇幅所限，大多数都不记录在本文里了。可以从他的slides（http://www.brendangregg.com/Slides/LSFMM2019_BPF_Observability.pdf）看到完整内容。上述的命令会报出syscall number，而不是syscall name。果然，马上就看到了新版本kernel下的一个问题，不过最终看来并不是导致ps出错的罪魁祸首，这条路就走到头了。

那么他接着转换了策略：也许某些system call发生了“successfully failing"（也就是syscall认为看到的异常现象也是应该正常返回的）。然后接着用bpftrace拿到更多信息，他终于得到了想要的回答：有时候getdents() system call对/proc/会只返回一部分数据（partial result），这样我们关注的目标进程就拿不到了，service也就误以为进程退出了。

所以，这里的问题应该来自/proc filesystem。然后他利用了ftrace等工具，仔细看了一下在出现partial result的时候调用到了哪些函数。然后再用回bpftrace来跟踪了几个代码分支，最后确定是find_ge_pid()提前停止了，正常时应该继续读下一个最大PID的。这里，其实是因为process-ID table实现有了变化。然后时间到了，他得出发来赶飞机参会了。

所以，他其实现在还没有解决这个问题。应该不难了，毕竟罪魁祸首找到了，后面应该能拿出解决方案了。不过，这些内容已经足够说明BPF对调查这个问题有多大帮助了。当前这些基于BPF的监控工具，最大的好处就是能够提供更好的bug report，描述清楚bug的更多信息。

One-liners

回到正题，Gregg介绍了一下BPF system的architecture（架构）。最底层，是BPF virtual machine。开发者可以写一些raw BPF代码来操作这个虚拟机，不过非常非常难，不会有人想要真这么做的。他在会场调查了一下有多少人写过raw BPF代码，看到房间里居然有那么多人举手，他表示震惊，也许全世界的raw BPF代码专家都坐在了这个房间吧。要想使用高级语言来操作虚拟机，可以使用LLVM的backend，能够用一个类 C语言 的方式来写BPF program。然后BCC就可以load这些program然后根据C或者 python 代码来决定执行流程。再上一层，就是今天介绍的bpftrace了，它可以用于写很方便的one-line tool，一行命令搞定丰富功能。例如，我们怎么知道page cache的readahead带来多大帮助？它是真的会加速I/O操作呢，还是会导致更多的cache污染来拖慢系统？现在不用去瞎想了，直接观测就好。他用bpftrace写了一个简单的工具，记录readahead引入各个page的时间戳，然后再拿时间戳跟真正用到这些page的时间戳做对比。运行他关心的workload之后，可以看到结果是几乎所有page都在被load到cache之后的32ms内被访问过，而从来没有访问（referenced）过的page非常少。所以，readhead在他的workload里面，证明是非常有帮助的，也说明他的application如果能配置更大的readahead的话，会运行的更加有效率。

人们可能会对上面这个场景里page cache的eviction（空间不够导致page被换出）也关心同样的performance数据。那么只要在这些page被换出的时候，查看这些page的存活时长，就能够用于评估page cache的size是否合理了。如果那些page已经很长时间没有被访问过了，说明page cache可能设置的太大了。不过这个功能他并没有实现出来，在座的如果谁有兴趣试试的话，他非常欢迎发出来给他抄抄。

他的检测readahead性能的工具其实不是one-liner（一行命令搞定）的，不过一页ppt也就能写得下了。说明bpftrace在创建这类小工具的时候，是非常高效的一个平台。用户只要提供一个probe(例如kernel的tracepoint)，一个可有可无的filter expression（过滤条件），以及一个action（probe触发的时候采取什么行动）。相关的语法非常像是awk或者DTrace。

bpftrace工具里面内置了一个parser，会把命令解析出来，创建相应的BPF program，然后在关注的event触发时调用。perf的ring buffer也被利用来从kernel高速取出大量数据。不过其实大多数数据都是在kernel里面先经过了分析处理，然后再用BPF maps给传递出来。Version 0.90在3月份刚刚release，下一个版本就是0.10很快会发布（很多人抱怨这个release版本号一定要改掉，看起来好像版本回退了一样）。

BPF everywhere

Gregg正在写一本书，介绍怎样利用BPF来进行performance分析的。与此同时他也在试着改进BPF系统，能把目前意识到的缺陷尽量解决。他用superping工具举了个例子，superping会附着（hook）到packet的send和receive events上，希望获取到更精确的ping时间点，不要包含scheduling latency（调度延迟）。不过最终他测出来的时间居然比普通的ping测出来的更加长了。最后他发现network stack好多年前已经解决了这个问题，因为timestamp存在packets里面，根本不需要这样一个工具。不过superping工具也确实演示出BPF怎样根据kernel的头文件来逐个structure的追踪分析。

还有一个挺有用的工具，tcplife，能够采集TCP connection的各种信息。这些信息通常都是用packet cature工具例如wireshark来采集的，不过采集都会造成不少cost。而tcplife能够直接hook进networking stack来获取这个connection从开始到结束的全生命周期的信息。最开始它是利用了kprobe监测tcp_set_state()，证明这个方案很有用之后，4.15 Linux kernel里面直接加了一个合适位置的tracepoint。tracepoint比kprobe要更加稳定。

不过Linux 4.16版本里面，这个tracepoint被挪到了inet_sock_set_state()，也提取了更多信息。这时Gregg的tool就不能用了（因为他的代码还在用旧的位置）。不过他觉得这也没关系，哪怕tracepoint经常会有改动，也总比用kprobe要方便的多。不过他提出了一个建议，最好tracepoint能增加一个pointer来供user space工具用。他知道用这个pointer可能是不可靠的，不过还是对工具有一些价值的。

这里也点出一个更加普适性的要点：kprobe能作为一个很好的试验tracepoint的方式。利用kprobe实现的工具，很可能会让大家有兴趣实现一个更合适的tracepoint，以及了解需要采集什么样的信息。这样在提交新的tracepoint的kernel patch的时候，能更好的证明它的必要性。

Gregg最终总结，尽管各种BPF工具提供了各种各样的信息，绝大多数的performance优化还是依赖图形化的工具来分析，而不是用command-line tool。不过，BPF在这些领域也更加重要。现在很容易能总结kernel的各个trace信息，减少采集performance data时的overhead（额外损失）。这些证明kernel community应该继续这个方向：”BPF all the things"（用BPF实现一切！）