如何选择一个 Linux Tracer

2.了解其他的Tracer

正如我一个朋友说的：“你不需要知道如何操作 X 射线机器，但是一旦你吞了一枚硬币，你得知道这得去做 X 射线”，你应该了解各种 tracer 都能做什么，这样就能在你工作中真正需要 tracer 的时候，你既可以选择稍后学习使用，也可以雇相应的人来完成。

简短来说：几乎所有的东西都可以使用 tracer 来进行分析和跟踪。如，文件系统，网络处理器，硬件驱动器，全部的应用程序。可以看一下我的个人网站上关于 ftrace的文章 ，还有我写的关于 perf_events 文档介绍，可以做为一个追踪(或者性能分析)的例子。

3. 寻求前端支持工具

如果你正想买一个能支持跟踪 Linux 的性能分析工具（有许多卖这类工具的公司）。想像一下，只需要直接点击一下界面就能“洞察”整个系统内核，包括隐藏的不同堆栈位置的热图，我在 Monitorama talk 中介绍了一个这样带图形界面的工具。

我开源了一些我自己开发的前端工具，尽管只是 CLI （命令行界面）而不是（图形界面）。这些工具也会让人们更加快速容易的使用 tracer。比如下面的例子，用我的 perf_tool，跟踪一个新进程:

# ./execsnoopTracing exec()s. Ctrl-C to end.    PID   PPID ARGS  22898  22004 man ls  22905  22898 preconv -e UTF-8  22908  22898 pager -s  22907  22898 nroff -mandoc -rLL=164n -rLT=164n -Tutf8 [...]

在 Netflix 上，我们创建了一个 Vector ，一个分析工具的实例同时也是 Linux 上的 tracer 的最终前端。

致性能或内核工程师

我们的工作变的越来越困难，很多的人会问我们怎么样去追踪，哪种路径可以用！为了正确理解一个路径，你经常需要花上至少100个小时才能做到。理解所有的 linux 路径去做出理性的决定是一个浩大的工程。（我可能是唯一一个接近做到这件事情的人）

这里是我的建议，可以二选其一：

A) 选中一个全能的路径，并且使它标准化，这将涉及花费大量的时间去弄清楚它在测试环境中的细微差别和安全性。我现在推荐 SystemTap 的最新版本（ie，从 源代码 构建）。我知道有些公司已经选用 LTTng，而且他们用的很好，尽管它不是非常的强大（虽然它更安全）。Sysdig 可以成为另一个候选如果它可以增加追踪点或者 kprobes。

B) 遵循我上面提供的流程图，它将意味着尽可能更多的使用 ftrace 或者 perf_event， eBPF 会得到整合，之后其他的路径像 SystemTap/LTTng 会去填补这个空白。 这就是我目前在 Netflix 做的工作。

tracer 的评论：

1. ftrace

我喜欢用 ftrace，它是内核 hacker 的首选，内置于系统内核，可以使用跟踪点(静态检查点)，能调用内核 kprobes 和 uprobes 调试工具。并且提供几个这样的功能：带可选过滤器和参数的事件追踪功能；在内核中进行统计的事件计数和定时功能；还有函数流程遍历的功能。可以看一下内核代码中 ftrace.txt 例子了解一下。ftrace 由 /sys 控制，仅支持单一的 root 用户使用（但是你可以通过缓冲区实例破解以支持多用户）。某些时候 Ftrace 的操作界面非常繁琐，但是的确非常“hack”，而且它有前端界面。Steven Rostedt，ftace 的主要作者，创建了 trace-cmd 命令工具，而我创建了 perf 的工具集。我对这个工具最大的不满就是它不可编程。举例来说，你不能保存和获取时间戳，不能计算延迟，不能把这些计算结果保存成直方图的形式。你需要转储事件至用户级别，并且花一些时间去处理结果。ftrace 可以通过 eBPF 变成可编程的。

2.perf_events

perf_events 是 Linux 用户的主要跟踪工具，它内置在内核源码中，通常通过 linux-tools-commom 加入。也称“perf”，同前端工具名称，通常用来跟踪和转储信息到一个叫做 perf.data 的文件中，perf.data 文件相当于一个动态的缓冲区，用来保存之后需要处理的结果。ftrace 能做到的，perf_events 大都也可以做到，perf-events 不能做函数流程遍历，少了一点儿“hack”劲儿（但是对于安全/错误检查有更好的支持）。它可以进行 CPU 分析和性能统计，用户级堆栈解析，也可以使用对于跟踪每行局部变量产生的调试信息。它也支持多用户并发操作。和 ftrace 一样也不支持可编程。如果要我只推荐一款 tracer，那一定是 perf 了。它能解决众多问题，并且它相对较安全。

3. eBPF

extended Berkeley Packet Filter（eBPF）是一个可以在事件上运行程序的高效内核虚拟机（JIT）。它可能最终会提供 ftrace 和 perf_events 的内核编程，并强化其他的 tracer。这是 Alexei Starovoitov 目前正在开发的，还没有完全集成，但是从4.1开始已经对一些优秀的工具有足够的内核支持了，如块设备I/O的延迟热图。可参考其主要作者 Alexei Starovoitov 的 BPF slides 和  eBPF samples 。

4. SystemTap

SystemTap 是最强大的tracer。它能做所有事情，如概要分析，跟踪点，探针，uprobes（来自SystemTap），USDT和内核编程等。它将程序编译为内核模块，然后加载，这是一种获取安全的巧妙做法。它也是从tree发展而来，在过去有很多问题（多的可怕）。很多不是 SystemTap 本身的错——它常常是第一个使用内核追踪功能，也是第一个碰到 bug 的。SystemTap 的最新版本好多了（必须由源代码编译），但是很多人仍然会被早期版本吓到。如果你想用它，可先在测试环境中使用，并与irc.freenode.net上 的 #systemtap 开发人员交流。（Netflix 有容错机制，我们已经使用了 SystemTap，但是可能我们考虑的安全方面的问题比你们少。）我最大的不满是，它似乎认为你有常常没有的内核 debug 信息。实际上没有它也能做很多事情，但是缺少文档和例子（我必须自己全靠自己开始学习）。

5. LTTng

LTTng 优化了事件采集，这比其他 tracers 做得好。它从 tree 发展而来，它的核心很简单：通过一组小规模的固定指令集将事件写入追踪缓冲区，这种方式使它安全、快速，缺点是它没有内核编码的简单途径。我一直听说这不是一个大问题，因为尽管需要后期处理，它也已经优化到可以充分的度量。此外，它还首创了一个不同的分析技术，更多对所有关注事件的黑盒记录将稍后以 GUI 的方式进行研究。我关心的是前期没有考虑到要录制的事件缺失问题如何解决，但我真正要做的是花更多时间来看它在实践中用的怎么样。这是我花的时间最少的一个 tracer（没有什么特殊原因）。

6. Ktap

ktap 在过去是一款前景很好的 tracer，它使用内核中的 lua 虚拟机处理，在没有调试信息的情况下在嵌入式设备上运行的很好。它分为几个步骤，并在有一段时间似乎超过了 Linux 上所有的追踪器。然后 eBPF 开始进行内核集成，而 ktap 的集成在它可以使用 eBPF 替代它自己的虚拟机后才开始。因为 eBPF 仍将持续集成几个月，ktap 开发者要继续等上一段时间。我希望今年晚些时候它能重新开发。

7. dtrace4linux

dtrace4linux 主要是 Paul Fox 一个人在业余时间完成的，它是 Sun DTrace 的 Linux 版本。它引入瞩目，还有一些 provider 可以运行，但是从某种程度上来说还不完整，更多的是一种实验性的工具（不安全）。我认为，顾忌到许可问题，人们会小心翼翼的为 dtrace4linux 贡献代码：由于当年 Sun 开源DTrace 使用的是 CDDL 协议，而 dtrace4linux 也不大可能最终进入 Linux kernel。Paul 的方法很可能会使其成为一个 add-on。我很乐意看到 Linux 平台上的 DTrace 和这个项目的完成，我认为当我加入 Netflix 后将会花些时间来协助完成这个项目。然而，我还是要继续使用内置的 tracers，如 ftrace 和 perf_events。

8.OL DTrace

Oracle Linux DTrace 为了将 DTrace 引入 Linux，特别是 Oracle Linux，做出了很大的努力。这些年来发布的多个版本表明了它的稳定进展。开发者们以一种对这个项目的前景看好的态度谈论着改进 DTrace 测试套件。很多有用的 provider 已经完成了，如：syscall, profile, sdt, proc, sched 以及 USDT。我很期待 fbt（function boundary tracing, 用于内核动态跟踪）的完成，它是 Linux 内核上非常棒的 provider。OL DTrace 最终的成功将取决于人们对运行 Oracle Linux（为技术支持付费）有多大兴趣，另一方面取决于它是否完全开源：它的内核元件是开源的，而我没有看到它的用户级别代码。

9. sysdig

sysdig 是一个使用类tcpdump语法来操作系统事件的新tracer，它使用lua提交进程。它很优秀，它见证了系统跟踪领域的变革。它的局限性在于它只在当前进行系统调用，在提交进行时将所有事件转储为用户级别。你可以使用系统调用做很多事情，然而我还是很希望它能支持跟踪点、kprobe和uprobe。我还期待它能支持eBPF做内核摘要。目前，sysdig开发者正在增加容器支持。留意这些内容。

延伸阅读

我关于 tracer 的工作包括：

ftrace：我的 perf-tools 工具集（参考实例目录）；我在 lwn.net 上的 关于ftrace的文章 ；  LISA14 的发言；还有帖子： 函数计数 ， iosnoop ， opensnoop ， execsnoop ， TCP转发 ， uprobes 以及 USDT 。

perf_evenets：我的网页 perf_events实例 ；SCALE上的发言 Netflix的Linux性能分析 ；还有帖子CPU 采样 ， 静态追踪点 ， 热点图 ， 计数 ， 内核行追踪 ， off-CPU时间图 。

eBPF：帖子 eBPF：迈出一小步 ，和一些  BPF工具 （我需要发布更多）。

SystemTap：我很久以前写了一篇有点过期的帖子 使用SystemTap 。最近，我发布了一些工具  systemtap-lwtools 来演示如何在没有内核诊断信息的情况下使用SystemTap。

LTTng：我只花了一点时间，还不足以发表任何内容。

ktap：我的网页 ktap实例 包含一些早期版本的单行小程序和脚本。

dtrace4linux：我在 系统性能 一书中给出了一些实例，并曾经开发了一些小的修复程序，如  timestamps 。

OL DTrace：由于它直接由DTrace转变而来，很多我早期关于DTrace的工作都有相关性（如果在这里给出链接的话就太多了，可以在 我的主页 上搜索）。当它更完善时，我会开发一些特殊工具。

sysdig：我向 fileslower 和 subsecond offset spectrogram 贡献了代码。

其他：我写了关于  strace 的注意事项。

请不要有更多的 tracer！如果你想知道为什么 Linux 不仅仅只有一个 tracer，或者只用本身的DTrace，你可以在我的演讲稿 从DTrace到Linux 中找到答案，从28张幻灯片开始。

感谢 Deirdré Straughan 的编辑，以及与 General Zoi 的小马宝莉创作者一起创作的 tracing 小马。