LWN：统一kernel tracing处理！

点击上方蓝色“Linux News搬运工”关注我们~

Unifying kernel tracing

By Jake Edge
October 30, 2019

---

OSS EU

本文译自：https://lwn.net/Articles/803347/

Steven Rostedt在Linux kernel tracing社区里参与了很长时间，差不多从这个模块建立就开始了。他开发了ftrace，这是Linux kernel里在tracing方面最早加入的功能之一。现在kernel里有非常多的tracing功能了。法国里昂举行的2019 Open Source Summit Europe峰会上，Rostedt给大家讲述了他长时间思考之后的一个想法：创建一个统一的tracing platform（平台），能让user space程序来访问kernel的所有tracing功能。

Linux中的tracing机制相关的有很多应用程序，包括perf, LTTng, SystemTap, DTrace, BPF, ktap, strace, GDB, ftrace，其实还有更多的。他首先介绍了一下Linux tracing的历史，介绍了这些项目的来历。

Tracing history

ftrace其实是Rostedt在1998年做硕士论文的时候开始开发的。他当时创建了一个"logdev"机制，能比printk()更快的把输出信息放到ring buffer里。他当时在调查网络服务质量（QoS）的行为，printk()对他来说太慢了。后来他在Timesys工作之后，需要能更快地从公司的实时内核里面提取出信息，因此他自然就把logdev加到这个平台上了。第一版的logdev是在2.0内核上开发的，后来移植到2.2, 2.4等等新出来的kernel上。其实他开发ftrace的时候都是利用logdev来调试的。而logdev就是ftrace的两个来源之一。

另一个来源是实时补丁（realtime patch set）中带有的latency tracer。这是2004年Ingo Molnar和Nadia Chambers创建的。latency tracer利用了GCC的profiling功能，会在每个函数的最开头调用mcount()，这样就可以用来跟踪kernel的执行流程了。latency tracer不是动态的，因为function tracing不能在运行时进行控制，只能在编译时决定是否加入。

2008年的时候，Rostedt正在Red Hat的realtime团队工作，当时这个团队做了很多工作希望能把realtime patch推到kernel mainline上去。Arnaldo Carvalho de Melo试过把latency tracer移植到upstream kernel，不过这个tracer确实太复杂了，它会调用trace()，其中会调用_trace()，然后一直这样调下去，直到有5个下划线的_____trace()，蔚为奇观。Rostedt对这部分代码很熟悉，所以进行了清理，并且利用上了logdev，最终成型为ftrace。

接下来讲到perf，这在一开始是作为“profiling utility done correctly（正确实现的profiling工具）”来开发的，当时围绕着oprofile和其他一些profiling方案有很多争论，希望用perf来解决。除了profiling功能外，perf还有一些tracing功能，主要是通过利用ftrace架构来实现的。Molnar希望Rostedt停止开发ftrace，专注于完善perf，不过Rostedt没有按照这个方向走，其中一个原因是他希望保留ftrace的debugfs接口。用户空间可以直接利用debugfs来访问ftrace，不需要使用任何工具，这样对于没有内置很多工具的嵌入式Linux系统来说非常方便，只要用BusyBox的echo命令就能打开tracing功能，简单cat一下就可以拿到tracing结果。

在LTTng之前，有一个名为Linux Trace Toolkit (LTT)的工具，是由Karim Yaghmour在2000年左右创建的。当时这其实是第一次真正想把tracing方案加入mainline，不过后来Molnar和Linus Torvalds反对，所以没能成功。

而LTT的下一代（next generation，即ng）其实是由Mathiew Desnoyers在2006年完全重写过的版本。Rostedt说，当年Desnoyers其实后悔不应该在名字中保留LTT，因为基本上代码关联很少，并且这样会导致不少人认为这只是LTT的一个扩展。虽然LTTng从来没有能合入upstream，一直作为独立的代码库而维护着，不过Desnoyers成功的把tracepoint合入mainline了。ftrace所用到的trace event就是基于tracepoint来实现的。

DTrace则是在kernel里第一个支持脚本编程的tracing工具。它起源于Solaris，于2005年正式发布。Oracle收购Sun之后就把DTrace移植到Linux上了，不过直到2017年才按照GPL进行了开源。对多数人来说这个太晚了，所以DTrace基本就只有Oracle Linux（可能还有其他一些平台）在用。很有意思的是，有人说DTrace来自IBM的dprobe，dprobe确实非常早，当时已经在SUSE Linux Enterprise Server (SLES) kernel里面使用起来了。每个人都是在其他人的工作基础上进行开发的，就像那句名言所说“站在巨人的肩膀上”。

Red Hat中类似DTrace的方案是SystemTap，2009年发布。这个方案跟其他有一点很类似：都没能进入mainline kernel。想要让SystemTap, LTTng和其他方案合入mainline的话，其中一个困难是这些项目都只是专注于tracer这一部分但却从来没有向其他开发者推销这些工具有多么好用。

ftrace本质上并不是一个tracing工具，不过起初合入它到mainline有部分原因是为了准备后续合入realtime patch，realtime patch很需要ftrace的调试能力。他此前同Desnoyers合作把tracepoint合入kernel，然后开始让其他开发者能在自己的子系统里面轻松添加trace event。那些用来创建trace event的宏看起来非常吓人，不过用起来很方便。所以ftrace起初能够得门而入之后，其他开发者越来越认识到它的价值，因此不断的得到充实。现在mainline kernel里面有超过1000种trace event了。

开发者可以轻松使用宏来定义trace event，然后这个event就会在tracefs的目录结构中出现一个对应的文件节点。简单的对此文件进行echo 1操作就能打开这个trace event使之出现在tracing输出信息里。等kernel开发者意识到这有多么方便好用之后，他们就开始对tracing更加感兴趣，也就希望kernel能拥有更多的tracing功能。在2008年Kernel Summit上，Torvalds宣布SystemTap过于复杂，大家应该继续完善kernel内部的简化版的tracing工具。Rostedt认为，早期工具的目标就应该是尽量简单。

然后介绍到了BPF。在2011年，针对x86平台的BPF增加了一个just-in-time (JIT) compiler，这样就使得网络包过滤的定制化工作特别迅速。2014年的时候，Alexei Starovoitov引入了extended BPF (eBPF），能够让BPF program应用于kernel的其他领域，包括tracing在内。基于eBPF的tracing让Linux拥有了DTrace和SystemTap希望实现的那些能力。现在，DTrace和SystemTap都在进行重构，希望底层直接利用eBPF，这样这些工具的现有客户使用的脚本就能直接在mainline kernel上使用了。

Status

他提到2017年Julia Evans的tweet消息中描述了Linux tracing的状态，后来她改进发布了一篇很长的博文。其中大多数内容跟现状是非常吻合的。经常有人问他“为什么我们不能只用一个trace工具？”不少人都认为太多选择都是件很麻烦的事情，不过他对这些人的建议是换到macOS去吧。

针对多种trace工具并存的抱怨，其中一部分原因是这会分散开发者的力量，不过他相信“多样化能带来创新”。假如Bell System在上世纪80年代的时候没有分拆，那么我们就不会看到通讯市场的这么多选择，现在我们估计还在用拨盘电话呢，估计很多人都不认识这样的设备了。

在tracing领域，没有一个方案能适用于所有场景。就类似于用TAB还是用空格的争论，或者Emacs和Vim的争论一样。tracing用户通常有各自不同的目标，就像我们虽然可以开一辆货车到另一个城市去，但是更佳的选择应该是开跑车或者摩托才对。不同场景有不同需求，最好能有多种工具来共同解决。

他说，有人抱怨多样化毁掉了Unix，因为Unix有太多种变种，导致了它的衰落。其实这些变种全部都是私有软件、商业软件，他们没有共享彼此的功能。在私有软件世界里，从别人的代码上分支出来是在做坏事，而开源软件这里则是件好事。这些新分支能让大家尝试一些不同的、出乎意料的方式，如果结果是正面的，那么就可以合入到原分支上去。他认为“多样性正是开源软件的力量，因为我们总是能互相共享成果”。

Commonalities

在不同的trace工具之间有很多部分是共享的。所有方案里面都用到了tracepoint，也用到了kernel probe (kprobe)和user space probe (uprobes)。ftrace的function hook也在绝大多数trace工具里面都用到了。他展示了上面这张框图来说明Linux各种trace工具之中公用的部分。虚线上面一半都是各种user-space的部分，底下这一半是各种kernel部分。

他的想法是，可以提供一个统一的user-space library函数库，能让这些各种不同的trace工具来调用所有这些kernel功能。可以从下面这个框图中看到user space的一个绿色模块（不过Libray词拼写错了）。这样效果上来说，每个工具就都能用到其他工具使用了的功能了。就像是让tracing世界的货车、跑车、摩托车都能共同利用kernel所提供的最大功能了。

Rostedt说在这个方向已经有一些进展了。Babeltrace是从LTTng项目出来的一个函数库，它能在多种不同的trace文件格式和Common Trace Format (CTF)之间进行转换。它的目的是能让任意的trace工具都可以读取、利用其他trace工具处理过的数据。

还有一个libtraceevent库，目前已经可以打包分发了，他在物色一些发行版的包管理员来帮助推动。这个代码存在于kernel源代码目录中（tools/lib/traceevent）。每当kernel写了一条原始格式的trace event data的时候，这些数据的格式都会在tracefs里面发布出来。perf, PowerTop, trace-cmd等工具都会利用这个格式信息。所有这些工具都会复制一份他写的代码来解析格式信息、跟数据结合起来。他此前建议这些项目直接复制代码就好，不过现在可以直接采用函数库的形式供调用，这样那些工具可以删掉复制的代码，直接和libtraceevent链接起来就好。

还有一个libperf函数库，封装了perf_event_open()系统调用。其实那个系统调用就是一个拥有数百个命令的ioctl()，用起来很复杂。libperf就提供了一套更合理的接口来使用perf_event_open()。这个项目还很早期，不过今后会能够帮助应用程序更好的利用perf的强大能力。

还有不少函数库在准备当中。例如libftrace，作为tracefs目录的接口，能允许用户start或者stop tracer，enable或者disable trace event，创建kprobe和uprobe，读取原始格式的tracing数据。libtrace-cmd就是一个高级一些的函数库了，允许其他应用程序来做trace-cmd所能做到的功能。类似的，libkshark则是一个GUI函数库，允许应用程序能做到KernelShark所实现的功能。这意味着KernelShark的功能不会仅仅局限于处理ftrace数据，其他的tracer也能利用这类GUI功能来展示它们自己的数据。

上述框图中新加的绿色方框，包含了所有这些函数库以及其他功能，共同构成了Linux环境下的统一的tracing平台，就作为Linux kernel提供的各种迥异的trace功能之上的一个抽象层。他建议把Unix模式的“做一件事，并且做完美”改进为Linux模式的“做一个函数库，并且做完美”。

Rostedt认为tracing工具已经不再互相竞争了。过去确实有不同tracing工具的争斗，这其实是好事，带来了更多创新，不过没有理由继续一直争斗下去。这些tracing项目可以互相吸取优点加强自身，就好像大家变成了电动跑车，电动摩托，电动货车。他总结说，Linux之所以能成为世界上最好的操作系统，正是因为它可以让我们大家把各种功能实现出来。

[I would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to attend Open Source Summit Europe in Lyon, France.]

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～