动态追踪技术下篇，内容包括方法论、调试符号、死亡进程、传统的调试技术、Y语言。内容穿越四海，纵贯九重天！

文末原文链接给出了动态追踪技术完全版，带链接，欢迎收藏阅读。另，连续输出技术干货，大家还吃得消吗？吃不消就吱一声！

前面我们介绍到火焰图这样的基于采样的可视化方法，它其实算是非常通用的方法了。不管是什么系统，是用什么语言编写的，我们一般都可以得到一张某种性能维度上的火焰图，然后轻松进行分析。但更多的时候，我们可能需要对一些更深层次的更特殊的问题进行分析和排查，此时就需要编写一系列专门化的动态追踪工具，有计划有步骤地去逼近真正的问题。

在这个过程当中，我们推荐的策略是一种所谓的小步推进、连续求问的方式。也就是说我们并不指望一下编写一个很庞大很复杂的调试工具，一下子采集到所有可能需要的信息，从而一下子解决掉最终的问题。相反，我们会把最终问题的假设，分解成一系列的小假设，然后逐步求索，逐步验证，不断确定会修正我们的方向，不断地调整我们的轨迹和我们的假设，以接近最终的问题。这样做有一个好处是，每一个步骤每一个阶段的工具都可以足够的简单，那么这些工具本身犯错的可能性就大大降低。Brendan也注意到他如果尝试编写多用途的复杂工具，这种复杂工具本身引入bug的可能性也大大提高了。而错误的工具会给出错误的信息，从而误导我们得出错误的结论。这是非常危险的。简单工具的另一大好处是，在采样过程当中对生产系统产生的开销也会相对较小，毕竟引入的探针数目较少，每个探针的处理程序也不会有太多太复杂的计算。这里的每一个调试工具都有自己的针对性，都可以单独使用，那么这些工具在未来得到复用的机会也大大提高。所以总的来说，这种调试策略是非常有益的。

值得一提的是，这里我们拒绝所谓的“大数据”的调试做法。即我们并不会去尝试一下子采集尽可能全的信息和数据。相反，我们在每一个阶段每一个步骤上只采集我们当前步骤真正需要的信息。在每一步上，基于我们已经采集到的信息，去支持或者修正我们原来的方案和原来的方向，然后去指导编写下一步更细化的分析工具。

另外，对于非常小频率发生的线上事件，我们通常会采用“守株待兔”的做法，也就是说我们会设一个阈值或其他筛选条件，坐等有趣的事件被我们的探针捕获到。比如在追踪小频率的大延时请求的时候，我们会在调试工具里，首先筛选出那些延时超过一定阈值的请求，然后针对这些请求，采集尽可能多的实际需要的细节信息。这种策略其实跟我们传统的尽可能多的采集全量统计数据的做法完全相反，正因为我们是有针对性地、有具体策略地进行采样分析，我们才能把损耗和开销降到最低点，避免无谓的资源浪费。

我觉得动态追踪技术很好地诠释了一句老话，那就是“知识就是力量”。

通过动态追踪工具，我们可以把我们原先对系统的一些认识和知识，转变成可以解决实际问题的非常实用的工具。我们原先在计算机专业教育当中，通过课本了解到的那些原本抽象的概念，比如说虚拟文件系统、虚拟内存系统、进程调度器等等，现在都可以变得非常鲜活和具体。我们第一次可以在实际的生产系统当中，真切地观察它们具体的运作，它们的统计规律，而不用把操作系统内核或者系统软件的源码改得面目全非。这些非侵入式的实时观测的能力，都得益于动态追踪技术。

这项技术就像是金庸小说里杨过使的那把玄铁重剑，完全不懂武功的人自然是使不动的。但只要会一些武功，就可以越使越好，不断进步，直至木剑也能横行天下的境界。所以但凡你有一些系统方面的知识，就可以把这把“剑”挥动起来，就可以解决一些虽然基本但原先都无法想象的问题。而且你积累的系统方面的知识越多，这把“剑”就可以使得越好。而且，还有一点很有意思的是，你每多知道一点，就立马能多解决一些新的问题。反过来，由于我们可以通过这些调试工具解决很多问题，可以测量和学习到生产系统里面很多有趣的微观或宏观方面的统计规律，这些看得见的成果也会成为我们学习更多的系统知识的强大动力。于是很自然地，这也就成为有追求的工程师的“练级神器”。

记得我在微博上面曾经说过，“鼓励工程师不断的深入学习的工具才是有前途的好工具”。这其实是一个良性的相互促进的过程。

前面我们提到，动态追踪技术可以把正在运行的软件系统变成一个可以查询的实时只读数据库，但是做到这一点通常是有条件的，那就是这个软件系统得有比较完整的调试符号。那么调试符号是什么呢？调试符号一般是软件在编译的时候，由编译器生成的供调试使用的元信息。这些信息可以把编译后的二进制程序里面的很多细节信息，比如说函数和变量的地址、数据结构的内存布局等等，映射回源代码里面的那些抽象实体的名称，比如说函数名、变量名、类型名之类。Linux世界常见的调试符号的格式称为DWARF(1)（与英文单词“矮人”相同）。正是因为有了这些调试符号，我们在冰冷黑暗的二进制世界里面才有了一张地图，才有了一座灯塔，才可能去解释和还原这个底层世界里每一个细微方面的语义，重建出高层次的抽象概念和关系。

「矮人」为我们指明道路

通常也只有开源软件才容易生成调试符号，因为绝大多数闭源软件出于保密方面的原因，并不会提供任何调试符号，以增加逆向工程和破解的难度。其中有一个例子是Intel公司的IPP这个程序库。IPP针对Intel的芯片提供了很多常见算法的优化实现。我们也曾经尝试过在生产系统上面去使用基于IPP的gzip压缩库，但不幸的是我们遇到了问题——IPP会时不时的在线上崩溃。显然，没有调试符号的闭源软件在调试的时候会非常痛苦。我们曾经跟Intel的工程师远程沟通了好多次都没有办法定位和解决问题，最后只好放弃。如果有源代码，或者有调试符号，那么这个调试过程很可能会变的简单许多。

关于开源与动态追踪技术之间这种水乳相容的关系，BrendanGregg在他之前的一次分享当中也有提及。特别是当我们的整个软件栈（softwarestack）都是开源的时候，动态追踪的威力才有可能得到最大限度的发挥。软件栈通常包括操作系统内核、各种系统软件以及更上层的高级语言程序。当整个栈全部开源的时候，我们就可以轻而易举的从各个软件层面得到想要的信息，并将之转化为知识，转化为行动方案。

软件栈的典型构成

由于较复杂的动态追踪都会依赖于调试符号，而有些C编译器生成的调试符号是有问题的。这些含有错误的调试信息会导致动态追踪的效果打上很大的折扣，甚至直接阻碍我们的分析。比方说使用非常广泛的GCC这个C编译器，在4.5这个版本之前生成的调试符号质量是很差的，而4.5之后则有了长足的进步，尤其是在开启编译器优化的情况下。

前面提到，动态追踪技术一般是基于操作系统内核的，而对于我们平时使用非常广泛的Linux操作系统内核来说，其动态追踪的支持之路是一个漫长而艰辛的过程。其中一个主要原因或许是因为Linux的老大Linus一直觉得这种技术没有必要。

最初RedHat公司的工程师为Linux内核准备了一个所谓的utrace(2)）的补丁，用来支持用户态的动态追踪技术。这是SystemTap这样的框架最初仰赖的基础。在漫长的岁月里，RedHat家族的Linux发行版都默认包含了这个utrace补丁，比如RHEL、CentOS和Fedora之类。在那段utrace主导的日子里，SystemTap只在RedHat系的操作系统中有意义。这个utrace补丁最终也未能合并到主线版本的Linux内核中，它被另一种折衷的方案所取代。

Linux主线版本很早就拥有了kprobes(3)这种机制，可以动态地在指定的内核函数的入口和出口等位置上放置探针，并定义自己的探针处理程序。

用户态的动态追踪支持姗姗来迟，经历了无数次的讨论和反复修改。从官方Linux内核的3.5这个版本开始，引入了基于inode的uprobes(4)内核机制，可以安全地在用户态函数的入口等位置设置动态探针，并执行自己的探针处理程序。再后来，从3.10的内核开始，又融合了所谓的uretprobes(5)这个机制，可以进一步地在用户态函数的返回地址上设置动态探针。uprobes和uretprobes加在一起，终于可以取代utrace的主要功能。utrace补丁从此也完成了它的历史使命。而SystemTap现在也能在较新的内核上面，自动使用uprobes和uretprobes这些机制，而不再依赖于utrace补丁。

最近几年Linux的主线开发者们，把原来用于防火墙的netfilter里所使用的动态编译器，即BPF(6)，扩展了一下，得到了一个所谓的eBPF(7)，可以作为某种更加通用的内核虚拟机。通过这种机制，我们其实可以在Linux中构建类似DTrace那种常驻内核的动态追踪虚拟机。而事实上，最近已经有了一些这方面的尝试，比如说像BPF编译器(8)（BCC）这样的工具，使用LLVM工具链来把C代码编译为eBPF虚拟机所接受的字节码。总的来说，Linux的动态追踪支持是变得越来越好的。特别是从3.15版本的内核开始，动态追踪相关的内核机制终于变得比较健壮和稳定了。

我们看到动态追踪技术在软件系统的分析当中可以扮演非常关键的角色，那么很自然地会想到，是否也可以用类似的方法和思想去追踪硬件。

我们知道其实操作系统是直接和硬件打交道的，那么通过追踪操作系统的某些驱动程序或者其他方面，我们也可以间接地去分析与之相接的硬件设备的一些行为和问题。同时，现代硬件，比如说像Intel的CPU，一般会内置一些性能统计方面的寄存器（HardwarePerformanceCounter(9)），通过软件读取这些特殊寄存器里的信息，我们也可以得到很多有趣的直接关于硬件的信息。比如说Linux世界里的perf(10)工具最初就是为了这个目的。甚至包括VMWare这样的虚拟机软件也会去模拟这样特殊的硬件寄存器。基于这种特殊寄存器，也产生了像Mozillarr(11)这样有趣的调试工具，可以高效地进行进程执行过程的录制与回放。

直接对硬件内部设置动态探针并实施动态追踪，或许目前还存在于科幻层面，欢迎有兴趣的同学能够贡献更多的灵感和信息。

我们前面看到的其实都是对活着的进程进行分析，或者说正在运行的程序。那么死的进程呢？对于死掉的进程，其实最常见的形式就是进程发生了异常崩溃，产生了所谓的coredump(12)文件。其实对于这样死掉的进程剩下的“遗骸”，我们也可以进行很多深入的分析，从而有可能确定它的死亡原因。从这个意义上来讲，我们作为程序员扮演着「法医」这样的角色。

最经典的针对死进程遗骸进行分析的工具便是鼎鼎大名的GNUDebugger(13)（GDB）。那么LLVM世界也有一个类似的工具叫做LLDB(14)。显然，GDB原生的命令语言是非常有局限的，我们如果手工逐条命令地对coredump进行分析其实能得到地信息也非常有限。其实大部分工程师分析coredump也只是用btfull命令查看一下当前的C调用栈轨迹，抑或是利用inforeg命令查看一下各个CPU寄存器的当前取值，又或者查看一下崩溃位置的机器代码序列，等等。而其实更多的信息深藏于在堆（heap）中分配的各种复杂的二进制数据结构之中。对堆里的复杂数据结构进行扫描和分析，显然需要自动化，我们需要一种可编程的方式来编写复杂的coredump的分析工具。

顺应此需求，GDB在较新的版本当中（我记得好像是从7.0开始的），内置了对Python脚本的支持(15)。我们现在可以用Python来实现较复杂的GDB命令，从而对coredump这样的东西进行深度分析。事实上我也用Python写了很多这样的基于GDB的高级调试工具，甚至很多工具是和分析活体进程的SystemTap工具一一对应起来的。与动态追踪类似，借助于调试符号，我们可以在黑暗的“死亡世界”中找到光明之路。

黑暗世界里的光明之路

不过这种做法带来的一个问题是，工具的开发和移植变成了一个很大的负担。用Python这样的脚本语言来对C风格的数据结构进行遍历并不是一件有趣的事情。这种奇怪的Python代码写多了真的会让人抓狂。另外，同一个工具，我们既要用SystemTap的脚本语言写一遍，然后又要用GDB的Python代码来写一遍：无疑这是一个很大的负担，两种实现都需要仔细地进行开发和测试。它们虽然做的是类似的事情，但实现代码和相应的API都完全不同（这里值得一提的是，LLVM世界的LLDB工具也提供了类似的Python编程支持，而那里的PythonAPI又和GDB的不相兼容）。

我们当然也可以用GDB对活体程序进行分析，但和SystemTap相比，GDB最明显的就是性能问题。我曾经比较过一个较复杂工具的SystemTap版和GDBPython版。它们的性能相差有一个数量级。GDB显然不是为这种在线分析来设计的，相反，更多地考虑了交互性的使用方式。虽然它也能以批处理的方式运行，但是内部的实现方式决定了它存在非常严重的性能方面的限制。其中最让我抓狂的莫过于GDB内部滥用longjmp(16)来做常规的错误处理，从而带来了严重的性能损耗，这在SystemTap生成的GDB火焰图上是非常明显的。幸运地是，对死进程的分析总是可以离线进行，我们没必要在线去做这样的事情，所以时间上的考虑倒并不是那么重要了。然而不幸的是，我们的一些很复杂的GDBPython工具，需要运行好几分钟，即使是离线来做，也是让人感到很挫败的。

我自己曾经使用SystemTap对GDB+Python进行性能分析，并根据火焰图定位到了GDB内部最大的两处执行热点。然后，我给GDB官方提了两个C补丁，一是针对Python字符串操作(17)，一是针对GDB的错误处理方式(18)。它们使得我们最复杂的GDBPython工具的整体运行速度提高了%。GDB官方目前已经合并了其中一个补丁。使用动态追踪技术来分析和改进传统的调试工具，也是非常有趣的。

我已经把很多从前在自己的工作当中编写的GDBPython的调试工具开源到了GitHub上面，有兴趣的同学可以去看一下。一般是放在nginx-gdb-utils(19)这样的GitHub仓库里面，主要针对Nginx和LuaJIT。我曾经利用这些工具协助LuaJIT的作者MikePall定位到了十多个LuaJIT内部的bug。这些bug大多隐藏多年，都是Just-in-Time(JIT)编译器中的很微妙的问题。

由于死掉的进程不存在随时间变化的可能性，我们姑且把这种针对coredump的分析称之为“静态追踪”吧。

我编写的GDB调试命令

说到GDB，我们就不得不说一说动态追踪与传统的调试方法之间的区别与联系。细心的有经验的工程师应该会发现，其实动态追踪的“前身”就是在GDB里面设置断点，然后在断点处进行一系列检查的这种方式。只不过不同的是，动态追踪总是强调非交互式的批处理，强调尽可能低的性能损耗。而GDB这样的工具天然就是为交互操作而生的，所以实现并不考虑生产安全性，也不怎么在乎性能损耗。一般它的性能损耗是极大的。同时GDB所基于的ptrace(20)这种很古老的系统调用，其中的坑和问题也非常多。比如ptrace需要改变目标调试进程的父亲，还不允许多个调试者同时分析同一个进程。所以，从某种意义上来讲，使用GDB可以模拟一种所谓的“穷人的动态追踪”。

很多编程初学者喜欢使用GDB进行“单步执行”，而在真实的工业界的生产开发当中，这种方式经常是非常缺乏效率的。这是因为单步执行的时候往往会产生程序执行时序上的变化，导致很多与时序相关的问题无法再复现。另外，对于复杂的软件系统，单步执行很容易让人迷失在纷繁的代码路径当中，或者说迷失在所谓的“花园小径”当中，只见树木，不见森林。

所以，对于日常的开发过程当中的调试，其实我们还是推荐最简单也是看起来最笨的方法，即在关键代码路径上打印输出语句。这样我们通过查看日志等输出得到一个有很完整的上下文，从而能够有效进行分析的程序执行结果。当这种做法与测试驱动的开发方式结合起来的时候，尤为高效。显然，这种加日志和埋点的方式对于在线调试是不切合实际的，关于这一点，前面已经充分地讨论了。而另一方面，传统的性能分析工具，像Perl的DProf、C世界里的gprof、以及其他语言和环境的性能分析器（profiler），往往需要用特殊的选项重新编译程序，或者以特殊的方式重新运行程序。这种需要特别处理和配合的性能分析工具，显然并不适用在线的实时活体分析。

当今的调试世界是很凌乱的，正如我们前面看到的有DTrace、SystemTap、ePBF/BCC、GDB、LLDB这些，还有很多很多我们没有提到的，大家都可以在网络上查到。或许这从一个侧面反映出了我们所处的这个真实世界的混乱。

有时候我就在想，或许我们可以去设计并实现一种大一统的调试语言——事实上我连名字都起好了，那就是Y语言。我很希望能够实现这个Y语言，让它的编译器能够自动生成各种不同的调试框架和技术所接受的输入代码。比如说生成DTrace接受的D语言代码，生成SystemTap接受的stap脚本，还有GDB接受的Python脚本，以及LLDB的另一种不兼容API的Python脚本，抑或是eBPF接受的字节码，乃至BCC接受的某种C和Python代码的混合物。

如果我们设计的一个调试工具需要移植到多个不同的调试框架，那么显然人工移植的工作量是非常大的，正如我前面所提到的。而如果有这样一个大一统的Y语言，其编译器能够自动把同一份Y代码转换为针对各种不同调试平台的输入代码，并针对那些平台进行自动优化，那么每一种调试工具我们就只需要用Y语言写一遍就可以了。这将是巨大的解脱。而作为调试者本人，也没有必要亲自去学习所有那些具体的调试技术的凌乱的细节，亲自去踩每一种调试技术的“坑”。

这是我个人的一个美好愿景。

有朋友可能要问为什么要叫做Y呢?这是因为我的名字叫亦春，而亦字的汉语拼音的第一个字母就是Y……当然了，还有更重要的原因，那就是它是用来回答以「为什么」开头的问题的语言，而「为什么」在英语里面就是「why」，而why与Y谐音。

等Y语言诞生以后，我打算再找机会和大家多分享一些比较完整的动态追踪的实例。

好了，跟大家说了这么多，我就是想吸引更多的工程师来







































鍖椾含娌荤枟鐧界櫆椋庡摢瀹跺尰闄㈡渶鏉冨▉
鍖椾含娌荤櫧鐧滈�庣殑涓�鍖婚櫌

转载请注明原文网址：http://www.coolofsoul.com/phpfz/12890.html