~ 更新于 2017-11-02 ~

什么是 BPF?

BPF，及 伯克利包过滤器 B erkeley P acket F ilter ，最初构想提出于 1992 年，其目的是为了提供一种过滤包的方法，并且要避免从内核空间到用户空间的无用的数据包复制行为。它最初是由从用户空间注入到内核的一个简单的字节码构成，它在那个位置利用一个校验器进行检查 —— 以避免内核崩溃或者安全问题 —— 并附着到一个套接字上，接着在每个接收到的包上运行。几年后它被移植到 Linux 上，并且应用于一小部分应用程序上（例如，tcpdump）。其简化的语言以及存在于内核中的即时编译器（JIT），使 BPF 成为一个性能卓越的工具。

然后，在 2013 年，Alexei Starovoitov 对 BPF 进行彻底地改造，并增加了新的功能，改善了它的性能。这个新版本被命名为 eBPF （意思是 “extended BPF”），与此同时，将以前的 BPF 变成 cBPF（意思是 “classic” BPF）。新版本出现了如映射和 尾调用 tail call 这样的新特性，并且 JIT 编译器也被重写了。新的语言比 cBPF 更接近于原生机器语言。并且，在内核中创建了新的附着点。

感谢那些新的钩子，eBPF 程序才可以被设计用于各种各样的情形下，其分为两个应用领域。其中一个应用领域是内核跟踪和事件监控。BPF 程序可以被附着到探针（kprobe），而且它与其它跟踪模式相比，有很多的优点（有时也有一些缺点）。

另外一个应用领域是网络编程。除了套接字过滤器外，eBPF 程序还可以附加到 tc（Linux 流量控制工具）的入站或者出站接口上，以一种很高效的方式去执行各种包处理任务。这种使用方式在这个领域开创了一个新的天地。

并且 eBPF 通过使用为 IO Visor 项目开发的技术，使它的性能进一步得到提升：也为 XDP（“eXpress Data Path”）添加了新的钩子，XDP 是不久前添加到内核中的一种新式快速路径。XDP 与 Linux 栈组合，然后使用 BPF ，使包处理的速度更快。

甚至一些项目，如 P4、Open vSwitch，考虑 或者开始去接洽使用 BPF。其它的一些，如 CETH、Cilium，则是完全基于它的。BPF 是如此流行，因此，我们可以预计，不久之后，将围绕它有更多工具和项目出现 …

深入理解字节码

就像我一样：我的一些工作（包括 BEBA）是非常依赖 eBPF 的，并且在这个网站上以后的几篇文章将关注于这个主题。按理说，在深入到细节之前，我应该以某种方式去介绍 BPF —— 我的意思是，真正的介绍，在第一节所提供的简要介绍上更多地介绍在 BPF 上开发的新功能：什么是 BPF 映射？尾调用？内部结构是什么样子？等等。但是，在这个网站上已经有很多这个主题的介绍了，而且，我也不希望去写另一篇 “BPF 介绍” 的重复文章。

毕竟，我花费了很多的时间去阅读和学习关于 BPF 的知识，因此，在这里我们将要做什么呢，我收集了非常多的关于 BPF 的阅读材料：介绍、文档，也有教程或者示例。这里有很多的材料可以去阅读，但是，为了去阅读它，首先要去 找到 它。因此，为了能够帮助更多想去学习和使用 BPF 的人，现在的这篇文章给出了一个资源清单。这里有各种阅读材料，它可以帮你深入理解内核字节码的机制。

资源

简介

这篇文章中下面的链接提供了 BPF 的基本概述，或者，一些与它密切相关的一些主题。如果你对 BPF 非常陌生，你可以在这些介绍文章中挑选出一篇你喜欢的文章去阅读。如果你已经理解了 BPF，你可以针对特定的主题去阅读，下面是阅读清单。

关于 BPF

关于 eBPF 的常规介绍：

• 全面介绍 eBPF（Matt Flemming，on LWN.net，December 2017）：
  一篇写的很好的，并且易于理解的，介绍 eBPF 子系统组件的概述文章。
• 利用 BPF 和 XDP 实现可编程的内核网络数据路径 (Daniel Borkmann, OSSNA17, Los Angeles, September 2017)：
  快速理解所有的关于 eBPF 和 XDP 的基础概念的最好讲稿中的一篇（主要是关于网络处理的）
• BSD 包过滤器 （Suchakra Sharma, June 2017）：
  一篇非常好的介绍文章，主要是关于跟踪方面的。
• BPF：跟踪及更多（Brendan Gregg, January 2017）：
  主要内容是跟踪使用案例相关的。
• Linux BPF 的超强功能 （Brendan Gregg, March 2016）：
  第一部分是关于 火焰图 flame graph 的使用。
• IO Visor（Brenden Blanco, SCaLE 14x, January 2016）：
  介绍了 IO Visor 项目。
• 大型机上的 eBPF（Michael Holzheu, LinuxCon, Dubin, October 2015）
• 在 Linux 上新的（令人激动的）跟踪新产品（Elena Zannoni, LinuxCon, Japan, 2015）
• BPF — 内核中的虚拟机（Alexei Starovoitov, February 2015）：
  eBPF 的作者写的一篇讲稿。
• 扩展 extended BPF （Jonathan Corbet, July 2014）

BPF 内部结构：

• Daniel Borkmann 正在做的一项令人称奇的工作，它用于去展现 eBPF 的 内部结构，尤其是，它的关于 随同 tc 使用 的几次演讲和论文。

  • 使用 tc 的 cls\_bpf 的高级可编程和它的最新更新（netdev 1.2, Tokyo, October 2016）：
    Daniel 介绍了 eBPF 的细节，及其用于隧道和封装、直接包访问和其它特性。
  • 自 netdev 1.1 以来的 cls\_bpf/eBPF 更新 （netdev 1.2, Tokyo, October 2016, part of this tc workshop）
  • 使用 cls\_bpf 实现完全可编程的 tc 分类器 （netdev 1.1, Sevilla, February 2016）：
    介绍 eBPF 之后，它提供了许多 BPF 内部机制（映射管理、尾调用、校验器）的见解。对于大多数有志于 BPF 的人来说，这是必读的！全文在这里。
  • Linux tc 和 eBPF （fosdem16, Brussels, Belgium, January 2016）
  • eBPF 和 XDP 攻略和最新更新 （fosdem17, Brussels, Belgium, February 2017）
    这些介绍可能是理解 eBPF 内部机制设计与实现的最佳文档资源之一。

IO Visor 博客 有一些关于 BPF 的值得关注技术文章。它们中的一些包含了一点营销讨论。

内核跟踪：总结了所有的已有的方法，包括 BPF：

• 邂逅 eBPF 和内核跟踪 （Viller Hsiao, July 2016）：
  Kprobes、uprobes、ftrace
• Linux 内核跟踪（Viller Hsiao, July 2016）：
  Systemtap、Kernelshark、trace-cmd、LTTng、perf-tool、ftrace、hist-trigger、perf、function tracer、tracepoint、kprobe/uprobe …

关于 事件跟踪和监视，Brendan Gregg 大量使用了 eBPF，并且就其使用 eBPFR 的一些案例写了极好的文档。如果你正在做一些内核跟踪方面的工作，你应该去看一下他的关于 eBPF 和火焰图相关的博客文章。其中的大多数都可以 从这篇文章中 访问，或者浏览他的博客。

介绍 BPF，也介绍 Linux 网络的一般概念：

• Linux 网络详解 （Thomas Graf, LinuxCon, Toronto, August 2016）
• 内核网络攻略 (Thomas Graf, LinuxCon, Seattle, August 2015)

硬件 卸载 offload （LCTT 译注：“卸载”是指原本由软件来处理的一些操作交由硬件来完成，以提升吞吐量，降低 CPU 负荷。）：

• eBPF 与 tc 或者 XDP 一起支持硬件卸载，开始于 Linux 内核版本 4.9，是由 Netronome 提出的。这里是关于这个特性的介绍：eBPF/XDP 硬件卸载到 SmartNICs（Jakub Kicinski 和 Nic Viljoen, netdev 1.2, Tokyo, October 2016）
• 一年后出现的更新版：
  综合 XDP 卸载——处理边界案例（Jakub Kicinski 和 Nic Viljoen，netdev 2.2 ，Seoul，November 2017）
• 我现在有一个简短的，但是在 2018 年的 FOSDEM 上有一个更新版：
  XDP 硬件卸载的挑战（Quentin Monnet，FOSDEM 2018，Brussels，February 2018）

关于 cBPF：

• BSD 包过滤器：一个用户级包捕获的新架构 （Steven McCanne 和 Van Jacobson, 1992）：
  它是关于（经典）BPF 的最早的论文。
• BPF 的 FreeBSD 手册 是理解 cBPF 程序有用的资源。
• 关于 cBPF，Daniel Borkmann 做至少两个演讲，一是，在 2013 年 mmap 中，BPF 和 Netsniff-NG，以及 在 2014 中关于 tc 和 cls\_bpf 的的一个非常完整的演讲。
• 在 Cloudflare 的博客上，Marek Majkowski 提出的他的 与 iptables 的 xt_bpf 模块一起使用 BPF 字节码。值得一提的是，从 Linux 内核 4.10 开始，eBPF 也是通过这个模块支持的。（虽然，我并不知道关于这件事的任何讨论或者文章）
• Libpcap 过滤器语法

关于 XDP

• 在 IO Visor 网站上的 XDP 概述。
• eXpress Data Path (XDP) （Tom Herbert, Alexei Starovoitov, March 2016）：
  这是第一个关于 XDP 的演讲。
• BoF - BPF 能为你做什么？ （Brenden Blanco, LinuxCon, Toronto, August 2016）。
• eXpress Data Path （Brenden Blanco, Linux Meetup at Santa Clara, July 2016）：
  包含一些（有点营销的意思？）基准测试结果！使用单一核心：

+ ip 路由丢弃： ~3.6 百万包每秒（Mpps）
+ 使用 BPF，tc（使用 clsact qdisc）丢弃： ~4.2 Mpps
+ 使用 BPF，XDP 丢弃：20 Mpps （CPU 利用率 < 10%）
+ XDP 重写转发（在端口上它接收到的包）：10 Mpps（测试是用 mlx4 驱动程序执行的）。

• Jesper Dangaard Brouer 有几个非常好的幻灯片，它可以从本质上去理解 XDP 的内部结构。

  • XDP − eXpress Data Path，介绍及将来的用法 （September 2016）：
    “Linux 内核与 DPDK 的斗争” 。未来的计划（在写这篇文章时）它用 XDP 和 DPDK 进行比较。
  • 网络性能研讨 （netdev 1.2, Tokyo, October 2016）：
    关于 XDP 内部结构和预期演化的附加提示。
  • XDP – eXpress Data Path, 可用于 DDoS 防护 （OpenSourceDays, March 2017）：
    包含了关于 XDP 的详细情况和使用案例，以及 性能测试 的 性能测试结果 和 代码片断，以及使用 eBPF/XDP（基于一个 IP 黑名单模式）的用于 基本的 DDoS 防护。
  • 内存 vs. 网络，激发和修复内存瓶颈 （LSF Memory Management Summit, March 2017）：
    提供了许多 XDP 开发者当前所面对 内存问题 的许多细节。不要从这一个开始，但如果你已经理解了 XDP，并且想去了解它在页面分配方面的真实工作方式，这是一个非常有用的资源。
  • XDP 能为其它人做什么（netdev 2.1, Montreal, April 2017），及 Andy Gospodarek：
    普通人怎么开始使用 eBPF 和 XDP。这个演讲也由 Julia Evans 在 她的博客 上做了总结。
  • XDP 能为其它人做什么，第二版（netdev 2.2, Seoul, November 2017），同一个作者：
    该演讲的修订版本，包含了新的内容。

（Jesper 也创建了并且尝试去扩展了有关 eBPF 和 XDP 的一些文档，查看 相关节。）

• XDP 研讨 — 介绍、体验和未来发展（Tom Herbert, netdev 1.2, Tokyo, October 2016）
  在这篇文章中，只有视频可用，我不知道是否有幻灯片。
• 在 Linux 上进行高速包过滤 （Gilberto Bertin, DEF CON 25, Las Vegas, July 2017）
  在 Linux 上的最先进的包过滤的介绍，面向 DDoS 的保护、讨论了关于在内核中进行包处理、内核旁通、XDP 和 eBPF。

关于 基于 eBPF 或者 eBPF 相关的其它组件

• 在边界上的 P4 （John Fastabend, May 2016）：
  提出了使用 P4，一个包处理的描述语言，使用 BPF 去创建一个高性能的可编程交换机。
• 如果你喜欢音频的演讲，这里有一个相关的 OvS Orbit 片断(#11)，叫做 在边界上的 P4，日期是 2016 年 8 月。OvS Orbit 是对 Ben Pfaff 的访谈，它是 Open vSwitch 的其中一个核心维护者。在这个场景中，John Fastabend 是被访谈者。
• P4, EBPF 和 Linux TC 卸载 （Dinan Gunawardena 和 Jakub Kicinski, August 2016）：
  另一个 P4 的演讲，一些有关于 Netronome 的 NFP（网络流处理器）架构上的 eBPF 硬件卸载的因素。

• Cilium 是一个由 Cisco 最先发起的技术，它依赖 BPF 和 XDP 去提供 “基于 eBPF 程序即时生成的，用于容器的快速内核强制的网络和安全策略”。这个项目的代码 在 GitHub 上可以访问到。Thomas Graf 对这个主题做了很多的演讲：

  • Cilium：对容器利用 BPF & XDP 实现网络 & 安全，也特别展示了一个负载均衡的使用案例（Linux Plumbers conference, Santa Fe, November 2016）
  • Cilium：对容器利用 BPF & XDP 实现网络 & 安全 （Docker Distributed Systems Summit, October 2016 — video）
  • Cilium：使用 BPF 和 XDP 的快速 IPv6 容器网络 （LinuxCon, Toronto, August 2016）
  • Cilium： 用于容器的 BPF & XDP （fosdem17, Brussels, Belgium, February 2017）在上述不同的演讲中重复了大量的内容；嫌麻烦就选最近的一个。Daniel Borkmann 作为 Google 开源博客的特邀作者，也写了 Cilium 简介。
• 这里也有一个关于 Cilium 的播客节目：一个是 OvS Orbit episode (#4)，它是 Ben Pfaff 访谈 Thomas Graf （2016 年 5 月），和 另外一个 Ivan Pepelnjak 的播客，仍然是 Thomas Graf 关于 eBPF、P4、XDP 和 Cilium 方面的（2016 年 10 月）。

• Open vSwitch (OvS)，它是 Open Virtual Network（OVN，一个开源的网络虚拟化解决方案）相关的项目，正在考虑在不同的层次上使用 eBPF，它已经实现了几个概念验证原型：

  • 使用 eBPF 卸载 OVS 流处理器 （William (Cheng-Chun) Tu, OvS conference, San Jose, November 2016）
  • 将 OVN 的灵活性与 IOVisor 的高效率相结合 （Fulvio Risso, Matteo Bertrone 和 Mauricio Vasquez Bernal, OvS conference, San Jose, November 2016）据我所知，这些 eBPF 的使用案例看上去仅处于提议阶段（并没有合并到 OvS 的主分支中），但是，看它带来了什么将是非常值得关注的事情。
• XDP 的设计对分布式拒绝访问（DDoS）攻击是非常有用的。越来越多的演讲都关注于它。例如，在 2017 年 4 月加拿大蒙特利尔举办的 netdev 2.1 会议上，来自 Cloudflare 的人们的讲话（XDP 实践：将 XDP 集成到我们的 DDoS 缓解管道）或者来自 Facebook 的（Droplet：由 BPF + XDP 驱动的 DDoS 对策）都存在这样的很多使用案例。
• Kubernetes 可以用很多种方式与 eBPF 交互。这里有一篇关于 在 Kubernetes 中使用 eBPF 的文章，它解释了现有的产品（Cilium、Weave Scope）如何支持 eBPF 与 Kubernetes 一起工作，并且进一步描述了，在容器部署环境中，eBPF 感兴趣的交互内容是什么。
• CETH for XDP （Yan Chan 和 Yunsong Lu、Linux Meetup、Santa Clara、July 2016）：
  CETH，是由 Mellanox 发起的，为实现更快的网络 I/O 而主张的通用以太网驱动程序架构。
• VALE 交换机，另一个虚拟交换机，它可以与 netmap 框架结合，有 一个 BPF 扩展模块。

• Suricata，一个开源的入侵检测系统，它的旁路捕获旁特性依赖于 XDP。有一些关于它的资源：

  • Suricate 文档的 eBPF 和 XDP 部分
  • SEPTun-Mark-II （Suricata Extreme 性能调优指南 — Mark II）， Michal Purzynski 和 Peter Manev 发布于 2018 年 3 月。
  • 介绍这个特性的博客文章 Éric Leblond 发布于 2016 年 9 月。
  • Suricate 的 eBPF 历险记 （Éric Leblond, netdev 1.2, Tokyo, October 2016）
  • eBPF 和 XDP 一窥 （Éric Leblond, Kernel Recipes, Paris, September 2017）当使用原生驱动的 XDP 时，这个项目要求实现非常高的性能。
• InKeV：对于 DCN 的内核中分布式网络虚拟化 （Z. Ahmed, M. H. Alizai 和 A. A. Syed, SIGCOMM, August 2016）：
  InKeV 是一个基于 eBPF 的虚拟网络、目标数据中心网络的数据路径架构。它最初由 PLUMgrid 提出，并且声称相比基于 OvS 的 OpenStack 解决方案可以获得更好的性能。
• gobpf - 在 Go 中使用 eBPF （Michael Schubert, fosdem17, Brussels, Belgium, February 2017）：
  “一个来自 Go 库，可以去创建、加载和使用 eBPF 程序”
• ply 是为 Linux 实现的一个小而灵活的开源动态 跟踪器，它的一些特性非常类似于 bcc 工具，是受 awk 和 dtrace 启发，但使用一个更简单的语言。它是由 Tobias Waldekranz 写的。
• 如果你读过我以前的文章，你可能对我在这篇文章中的讨论感兴趣，使用 eBPF 实现 OpenState 接口，关于包状态处理，在 fosdem17 中。

文档

一旦你对 BPF 是做什么的有一个大体的理解。你可以抛开一般的演讲而深入到文档中了。下面是 BPF 的规范和功能的最全面的文档，按你的需要挑一个开始阅读吧！

关于 BPF

• BPF 的规范（包含 classic 和 extended 版本）可以在 Linux 内核的文档中，和特定的文件 linux/Documentation/networking/filter.txt 中找到。BPF 使用以及它的内部结构也被记录在那里。此外，当加载 BPF 代码失败时，在这里可以找到 被校验器抛出的错误信息，这有助于你排除不明确的错误信息。
• 此外，在内核树中，在 eBPF 那里有一个关于 常见问答 的文档，它在文件 linux/Documentation/bpf/bpf\_design\_QA.txt 中。
• … 但是，内核文档是非常难懂的，并且非常不容易阅读。如果你只是去查找一个简单的 eBPF 语言的描述，可以去 IO Visor 的 GitHub 仓库，那儿有 它的概括性描述。
• 顺便说一下，IO Visor 项目收集了许多 关于 BPF 的资源。大部分分别在 bcc 仓库的 文档目录 中，和 bpf-docs 仓库 的整个内容中，它们都在 GitHub 上。注意，这个非常好的 BPF 参考指南 包含一个详细的 BPF C 和 bcc Python 的 helper 的描述。
• 想深入到 BPF，那里有一些必要的 Linux 手册页。第一个是 bpf(2) man 页面 关于 bpf() 系统调用，它用于从用户空间去管理 BPF 程序和映射。它也包含一个 BPF 高级特性的描述（程序类型、映射等等）。第二个是主要是处理希望附加到 tc 接口的 BPF 程序：它是 tc-bpf(8) man 页面，是 使用 BPF 和 tc 的一个参考，并且包含一些示例命令和参考代码。
• Jesper Dangaard Brouer 发起了一个 更新 eBPF Linux 文档 的尝试，包含 不同的映射。他有一个草案，欢迎去贡献。一旦完成，这个文档将被合并进 man 页面并且进入到内核文档。
• Cilium 项目也有一个非常好的 BPF 和 XDP 参考指南，它是由核心的 eBPF 开发者写的，它被证明对于 eBPF 开发者是极其有用的。

• David Miller 在 xdp-newbies 邮件列表中发了几封关于 eBPF/XDP 内部结构的富有启发性的电子邮件。我找不到一个单独的地方收集它们的链接，因此，这里是一个列表：

  • bpf.h 和你 …
  • 从语境上讲…
  • BPF 校验器概述最后一个可能是目前来说关于校验器的最佳的总结。
• Ferris Ellis 发布的 一个关于 eBPF 的系列博客文章。作为我写的这个短文，第一篇文章是关于 eBPF 的历史背景和未来期望。接下来的文章将更多的是技术方面，和前景展望。
• 每个内核版本的 BPF 特性列表 在 bcc 仓库中可以找到。如果你想去知道运行一个给定的特性所要求的最小的内核版本，它是非常有用的。我贡献和添加了链接到提交中，它介绍了每个特性，因此，你也可以从那里很容易地去访问提交历史。

关于 tc

当为了网络目的结合使用 BPF 与 tc （Linux 流量控制 t raffic c ontrol 工具）时，它可用于收集 tc 的常规功能的信息。这里有几个关于它的资源。

• 找到关于 Linux 上 QoS 的简单教程是很困难的。这里有两个链接，它们很长而且很难懂，但是，如果你可以抽时间去阅读它，你将学习到几乎关于 tc 的任何东西（虽然，没有什么关于 BPF 的)。它们在这里：怎么去实现流量控制 （Martin A. Brown, 2006），和 怎么去实现 Linux 的高级路由 & 流量控制 （LARTC） （Bert Hubert & al., 2002）。
• 在你的系统上的 tc 手册页面 并不是最新的，因为它们中的几个最近已经增加了内容。如果你没有找到关于特定的队列规则、分类或者过滤器的文档，它可能在最新的 tc 组件的手册页面 中。
• 一些额外的材料可以在 iproute2 包自已的文件中找到：这个包中有 一些文档，包括一些文件，它可以帮你去理解 tc 的 action 的功能。
  注意： 这些文件在 2017 年 10 月 已经从 iproute2 中删除，然而，从 Git 历史中却一直可用。
• 不完全是文档：有一个关于 tc 的几个特性的研讨会（包含过滤、BPF、tc 卸载、…） 由 Jamal Hadi Salim 在 netdev 1.2 会议上组织的（October 2016）。
• 额外信息 — 如果你使用 tc 较多，这里有一些好消息：我用这个工具 写了一个 bash 补完功能，并且它被包 iproute2 带到内核版本 4.6 和更高版中！

关于 XDP

• 对于 XDP 的一些 进展中的文档（包括规范） 已经由 Jesper Dangaard Brouer 启动，并且意味着将成为一个协作工作。正在推进的（2016 年 9 月）：你期望它去改变，并且或许在一些节点上移动（Jesper 称为贡献，如果你想去改善它）。
• 自来 Cilium 项目的 BPF 和 XDP 参考指南 … 好吧，这个名字已经说明了一切。

关于 P4 和 BPF

P4 是一个用于指定交换机行为的语言。它可以为多种目标硬件或软件编译。因此，你可能猜到了，这些目标中的一个就是 BPF … 仅部分支持的：一些 P4 特性并不能被转化到 BPF 中，并且，用类似的方法，BPF 可以做的事情，而使用 P4 却不能表达出现。不过，P4 与 BPF 使用 的相关文档，被隐藏在 bcc 仓库中。这个改变在 P4\_16 版本中，p4c 引用的编辑器包含 一个 eBPF 后端。

教程

Brendan Gregg 为想要 使用 bcc 工具 跟踪和监视内核中的事件的人制作了一个非常好的 教程。第一个教程是关于如何使用 bcc 工具，它有许多章节，可以教你去理解怎么去使用已有的工具，而 针对 Python 开发者的一篇 专注于开发新工具，它总共有十七节 “课程”。

Sasha Goldshtein 也有一些 Linux 跟踪研究材料 涉及到使用几个 BPF 工具进行跟踪。

Jean-Tiare Le Bigot 的另一篇文章提供了一个详细的（和有指导意义的）使用 perf 和 eBPF 去设置一个低级的跟踪器 的示例。

对于网络相关的 eBPF 使用案例也有几个教程。有一些值得关注的文档，包括一篇 eBPF 卸载入门指南，是关于在 Open NFP 平台上用 Netronome 操作的。其它的那些，来自 Jesper 的演讲，XDP 能为其它人做什么（及其第二版），可能是 XDP 入门的最好的方法之一。

示例

有示例是非常好的。看看它们是如何工作的。但是 BPF 程序示例是分散在几个项目中的，因此，我列出了我所知道的所有的示例。示例并不是总是使用相同的 helper（例如，tc 和 bcc 都有一套它们自己的 helper，使它可以很容易地去用 C 语言写 BPF 程序）

来自内核的示例

内核中包含了大多数类型的程序：过滤器绑定到套接字或者 tc 接口、事件跟踪/监视、甚至是 XDP。你可以在 linux/samples/bpf/ 目录中找到这些示例。

现在，更多的示例已经作为单元测试被添加到 linux/tools/testing/selftests/bpf 目录下，这里面包含对硬件卸载的测试或者对于 libbpf 的测试。

Jesper 的 Dangaard Brouer 在他的 prototype-kernel 仓库中也维护了一套专门的示例。 这些示例与那些内核中提供的示例非常类似，但是它们可以脱离内核架构（Makefile 和头文件）编译。

也不要忘记去看一下 git 相关的提交历史，它们介绍了一些特定的特性，也许包含了一些特性的详细示例。

来自包 iproute2 的示例

iproute2 包也提供了几个示例。它们都很明显地偏向网络编程，因此，这个程序是附着到 tc 入站或者出站接口上。这些示例在 iproute2/examples/bpf/ 目录中。

来自 bcc 工具集的示例

许多示例都是 与 bcc 一起提供的：

• 一些网络的示例放在相关的目录下面。它们包括套接字过滤器、tc 过滤器、和一个 XDP 程序。
• tracing 目录包含许多 跟踪编程 的示例。前面的教程中提到的都在那里。那些程序涉及了很大部分的事件监视功能，并且，它们中的一些是面向生产系统的。注意，某些 Linux 发行版（至少是 Debian、Ubuntu、Fedora、Arch Linux）、这些程序已经被 打包了 并且可以很 “容易地” 通过比如 # apt install bcc-tools 进行安装。但是在写这篇文章的时候（除了 Arch Linux），首先要求安装 IO Visor 的包仓库。
• 也有一些 使用 Lua 作为一个不同的 BPF 后端（那是因为 BPF 程序是用 Lua 写的，它是 C 语言的一个子集，它允许为前端和后端使用相同的语言）的一些示例，它在第三个目录中。
• 当然，bcc 工具 自身就是 eBPF 程序使用案例的值得关注示例。

手册页面

虽然 bcc 一般很容易在内核中去注入和运行一个 BPF 程序，将程序附着到 tc 接口也能通过 tc 工具自己完成。因此，如果你打算将 BPF 与 tc 一起使用，你可以在 tc-bpf(8) 手册页面 中找到一些调用示例。

代码

有时候，BPF 文档或者示例并不够，而且你只想在你喜欢的文本编辑器（它当然应该是 Vim）中去显示代码并去阅读它。或者，你可能想深入到代码中去做一个补丁程序或者为机器增加一些新特性。因此，这里对有关的文件的几个建议，找到你想要的函数只取决于你自己！

在内核中的 BPF 代码

• 文件 linux/include/linux/bpf.h 及其相对的 linux/include/uapi/bpf.h 包含有关 eBPF 的 定义，它们分别用在内核中和用户空间程序的接口。
• 相同的方式，文件 linux/include/linux/filter.h 和 linux/include/uapi/filter.h 包含了用于 运行 BPF 程序 的信息。
• BPF 相关的 主要的代码片断 在 linux/kernel/bpf/ 目录下面。系统调用的不同操作许可，比如，程序加载或者映射管理是在文件 syscall.c 中实现，而 core.c 包含了 解析器。其它文件的命名显而易见：verifier.c 包含 校验器（不是开玩笑的），arraymap.c 的代码用于与数组类型的 映射 交互，等等。
• 有几个与网络（及 tc、XDP ）相关的函数和 helpers 是用户可用，其实现在 linux/net/core/filter.c 中。它也包含了移植 cBPF 字节码到 eBPF 的代码（因为在运行之前，内核中的所有的 cBPF 程序被转换成 eBPF）。
• 相关于 事件跟踪 的函数和 helpers 都在 linux/kernel/trace/bpf\_trace.c 中。
• JIT 编译器 在它们各自的架构目录下面，比如，x86 架构的在 linux/arch/x86/net/bpfjitcomp.c 中。例外是用于硬件卸载的 JIT 编译器，它们放在它们的驱动程序下，例如 Netronome NFP 网卡的就放在 linux/drivers/net/ethernet/netronome/nfp/bpf/jit.c 。
• 在 linux/net/sched/ 目录下，你可以找到 tc 的 BPF 组件 相关的代码，尤其是在文件 act_bpf.c （action）和 cls_bpf.c（filter）中。
• 我并没有在 BPF 上深入到 事件跟踪 中，因此，我并不真正了解这些程序的钩子。在 linux/kernel/trace/bpf\_trace.c 那里有一些东西。如果你对它感 兴趣，并且想去了解更多，你可以在 Brendan Gregg 的演示或者博客文章上去深入挖掘。
• 我也没有使用过 seccomp-BPF，不过你能在 linux/kernel/seccomp.c 找到它的代码，并且可以在 linux/tools/testing/selftests/seccomp/seccomp\_bpf.c 中找到一些它的使用示例。

XDP 钩子代码

一旦装载进内核的 BPF 虚拟机，由一个 Netlink 命令将 XDP 程序从用户空间钩入到内核网络路径中。接收它的是在 linux/net/core/dev.c 文件中的 dev_change_xdp_fd() 函数，它被调用并设置一个 XDP 钩子。钩子被放在支持的网卡的驱动程序中。例如，用于 Netronome 硬件钩子的 ntp 驱动程序实现放在 drivers/net/ethernet/netronome/nfp/ 中。文件 nfp_net_common.c 接受 Netlink 命令，并调用 nfp_net_xdp_setup()，它会转而调用 nfp_net_xdp_setup_drv() 实例来安装该程序。

在 bcc 中的 BPF 逻辑

在 bcc 的 GitHub 仓库 能找到的 bcc 工具集的代码。其 Python 代码，包含在 BPF 类中，最初它在文件 bcc/src/python/bcc/\_\_init\_\_.py 中。但是许多我觉得有意思的东西，比如，加载 BPF 程序到内核中，出现在 libbcc 的 C 库中。

使用 tc 去管理 BPF 的代码

当然，这些代码与 iproute2 包中的 tc 中的 BPF 相关。其中的一些在 iproute2/tc/ 目录中。文件 f_bpf.c 和 m_bpf.c（和 e_bpf.c）各自用于处理 BPF 的过滤器和动作的（和 tc exec 命令，等等）。文件 q_clsact.c 定义了为 BPF 特别创建的 clsact qdisc。但是，大多数的 BPF 用户空间逻辑 是在 iproute2/lib/bpf.c 库中实现的，因此，如果你想去使用 BPF 和 tc，这里可能是会将你搞混乱的地方（它是从文件 iproute2/tc/tc\_bpf.c 中移动而来的，你也可以在旧版本的包中找到相同的代码）。

BPF 实用工具

内核中也带有 BPF 相关的三个工具的源代码（bpf_asm.c、 bpf_dbg.c、 bpf_jit_disasm.c），根据你的版本不同，在 linux/tools/net/ （直到 Linux 4.14）或者 linux/tools/bpf/ 目录下面：

• bpf_asm 是一个极小的 cBPF 汇编程序。
• bpf_dbg 是一个很小的 cBPF 程序调试器。
• bpf_jit_disasm 对于两种 BPF 都是通用的，并且对于 JIT 调试来说非常有用。
• bpftool 是由 Jakub Kicinski 写的通用工具，它可以与 eBPF 程序交互并从用户空间的映射，例如，去展示、转储、pin 程序、或者去展示、创建、pin、更新、删除映射。

阅读在源文件顶部的注释可以得到一个它们使用方法的概述。

与 eBPF 一起工作的其它必需的文件是来自内核树的两个用户空间库，它们可以用于管理 eBPF 程序或者映射来自外部的程序。这个函数可以通过 linux/tools/lib/bpf/ 目录中的头文件 bpf.h 和 libbpf.h（更高层面封装）来访问。比如，工具 bpftool 主要依赖这些库。

其它值得关注的部分

如果你对关于 BPF 的不常见的语言的使用感兴趣，bcc 包含 一个 BPF 目标的 P4 编译器以及 一个 Lua 前端，它可以被用以代替 C 的一个子集，并且（用 Lua ）替代 Python 工具。

LLVM 后端

这个 BPF 后端用于 clang / LLVM 将 C 编译到 eBPF ，是在 这个提交 中添加到 LLVM 源代码的（也可以在 这个 GitHub 镜像 上访问）。

在用户空间中运行

到目前为止，我知道那里有至少两种 eBPF 用户空间实现。第一个是 uBPF，它是用 C 写的。它包含一个解析器、一个 x86\_64 架构的 JIT 编译器、一个汇编器和一个反汇编器。

uBPF 的代码似乎被重用来产生了一个 通用实现，其声称支持 FreeBSD 内核、FreeBSD 用户空间、Linux 内核、Linux 用户空间和 Mac OSX 用户空间。它被 VALE 交换机的 BPF 扩展模块使用。

其它用户空间的实现是我做的：rbpf，基于 uBPF，但是用 Rust 写的。写了解析器和 JIT 编译器 （Linux 下两个都有，Mac OSX 和 Windows 下仅有解析器），以后可能会有更多。

提交日志

正如前面所说的，如果你希望得到更多的关于一些特定的 BPF 特性的信息，不要犹豫，去看一些提交日志。你可以在许多地方搜索日志，比如，在 git.kernel.org、在 GitHub 上、或者如果你克隆过它还有你的本地仓库中。如果你不熟悉 git，你可以尝试像这些去做 git blame <file> 去看看介绍特定代码行的提交内容，然后，git show <commit> 去看详细情况（或者在 git log 的结果中按关键字搜索，但是这样做通常比较单调乏味）也可以看在 bcc 仓库中的 按内核版本区分的 eBPF 特性列表，它链接到相关的提交上。

排错

对 eBPF 的追捧是最近的事情，因此，到目前为止我还找不到许多关于怎么去排错的资源。所以这里只有几个，是我在使用 BPF 进行工作的时候，对自己遇到的问题进行的记录。

编译时的错误

• 确保你有一个最新的 Linux 内核版本（也可以看 这个文档）。
• 如果你自己编译内核：确保你安装了所有正确的组件，包括内核镜像、头文件和 libc。
• 当使用 tc-bpf（用于去编译 C 代码到 BPF 中）的 man 页面提供的 bcc shell 函数时：我曾经必须添加包含 clang 调用的头文件：

__bcc() {
        clang -O2 -I "/usr/src/linux-headers-$(uname -r)/include/" \
                  -I "/usr/src/linux-headers-$(uname -r)/arch/x86/include/" \
                -emit-llvm -c $1 -o - | \
        llc -march=bpf -filetype=obj -o "`basename $1 .c`.o"
}

（现在似乎修复了）。

• 对于使用 bcc 的其它问题，不要忘了去看一看这个工具集的 答疑。
• 如果你从一个并不精确匹配你的内核版本的 iproute2 包中下载了示例，可能会由于在文件中包含的头文件触发一些错误。这些示例片断都假设安装在你的系统中内核的头文件与 iproute2 包是相同版本的。如果不是这种情况，下载正确的 iproute2 版本，或者编辑示例中包含的文件的路径，指向到 iproute2 中包含的头文件上（在运行时一些问题可能或者不可能发生，取决于你使用的特性）。

在加载和运行时的错误

• 使用 tc 去加载一个程序，确保你使用了一个与使用中的内核版本等价的 iproute2 中的 tc 二进制文件。
• 使用 bcc 去加载一个程序，确保在你的系统上安装了 bcc（仅下载源代码去运行 Python 脚本是不够的）。
• 使用 tc，如果 BPF 程序不能返回一个预期值，检查调用它的方式：过滤器，或者动作，或者使用 “直传” 模式的过滤器。
• 还是 tc，注意不使用过滤器，动作不会直接附着到 qdiscs 或者接口。
• 通过内核校验器抛出错误到解析器可能很难。内核文档或许可以提供帮助，因此，可以 参考指南 或者，万不得一的情况下，可以去看源代码（祝你好运！）。记住，校验器 不运行 程序，对于这种类型的错误，记住这点是非常重要的。如果你得到一个关于无效内存访问或者关于未初始化的数据的错误，它并不意味着那些问题真实发生了（或者有时候是，它们完全有可能发生）。它意味着你的程序是以校验器预计可能发生错误的方式写的，并且因此而拒绝这个程序。
• 注意 tc 工具有一个 verbose 模式，它与 BPF 一起工作的很好：在你的命令行尾部尝试追加一个 verbose。
• bcc 也有一个 verbose 选项：BPF 类有一个 debug 参数，它可以带 DEBUG_LLVM_IR、DEBUG_BPF 和 DEBUG_PREPROCESSOR 三个标志中任何组合（详细情况在 源文件中）。 为调试该代码，它甚至嵌入了 一些条件去打印输出代码。
• LLVM v4.0+ 为 eBPF 程序 嵌入一个反汇编器。因此，如果你用 clang 编译你的程序，在编译时添加 -g 标志允许你通过内核校验器去以人类可读的格式去转储你的程序。处理转储文件，使用：

$ llvm-objdump -S -no-show-raw-insn bpf_program.o

• 使用映射？你应该去看看 bpf-map，这是一个为 Cilium 项目而用 Go 创建的非常有用的工具，它可以用于去转储内核中 eBPF 映射的内容。也有一个用 Rust 开发的 克隆。
• 在 StackOverflow 上有个旧的 bpf 标签，但是，在这篇文章中从没用过它（并且那里几乎没有与新版本的 eBPF 相关的东西）。如果你是一位来自未来的阅读者，你可能想去看看在这方面是否有更多的活动（LCTT 译注：意即只有旧东西）。

更多！

• 如果你想轻松地 测试 XDP，有 一个配置好的 Vagrant 可以使用。你也可以 在 Docker 容器中 测试 bcc。
• 想知道 BPF 的 开发和活动 在哪里吗？好吧，内核补丁总是出自于 netdev 上的邮件列表（相关 Linux 内核的网络栈开发）：以关键字 “BPF” 或者 “XDP” 来搜索。自 2017 年 4 月开始，那里也有 一个专门用于 XDP 编程的邮件列表（是为了架构或者寻求帮助）。在 IO Visor 的邮件列表上也有许多的讨论和辨论，因为 BPF 是一个重要的项目。如果你只是想随时了解情况，那里也有一个 @IOVisor Twitter 帐户。

请经常会回到这篇博客中，来看一看 关于 BPF 有没有新的文章！

特别感谢 Daniel Borkmann 指引我找到了 更多的文档，因此我才完成了这个合集。

via: https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into-bpf/

作者：Quentin Monnet 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

使用 伯克利包过滤器 Berkeley Packet Filter （BPF） 编译器集合 Compiler Collection （BCC）工具深度探查你的 Linux 代码。

在 Linux 中出现的一种新技术能够为系统管理员和开发者提供大量用于性能分析和故障排除的新工具和仪表盘。它被称为 增强的伯克利数据包过滤器 enhanced Berkeley Packet Filter （eBPF，或 BPF），虽然这些改进并不是由伯克利开发的，而且它们不仅仅是处理数据包，更多的是过滤。我将讨论在 Fedora 和 Red Hat Linux 发行版中使用 BPF 的一种方法，并在 Fedora 26 上演示。

BPF 可以在内核中运行由用户定义的沙盒程序，可以立即添加新的自定义功能。这就像按需给 Linux 系统添加超能力一般。 你可以使用它的例子包括如下：

• 高级性能跟踪工具：对文件系统操作、TCP 事件、用户级事件等的可编程的低开销检测。
• 网络性能： 尽早丢弃数据包以提高对 DDoS 的恢复能力，或者在内核中重定向数据包以提高性能。
• 安全监控： 7x24 小时的自定义检测和记录内核空间与用户空间内的可疑事件。

在可能的情况下，BPF 程序必须通过一个内核验证机制来保证它们的安全运行，这比写自定义的内核模块更安全。我在此假设大多数人并不编写自己的 BPF 程序，而是使用别人写好的。在 GitHub 上的 BPF Compiler Collection (bcc) 项目中，我已发布许多开源代码。bcc 为 BPF 开发提供了不同的前端支持，包括 Python 和 Lua，并且是目前最活跃的 BPF 工具项目。

7 个有用的 bcc/BPF 新工具

为了了解 bcc/BPF 工具和它们的检测内容，我创建了下面的图表并添加到 bcc 项目中。

这些是命令行界面工具，你可以通过 SSH 使用它们。目前大多数分析，包括我的老板，都是用 GUI 和仪表盘进行的。SSH 是最后的手段。但这些命令行工具仍然是预览 BPF 能力的好方法，即使你最终打算通过一个可用的 GUI 使用它。我已着手向一个开源 GUI 添加 BPF 功能，但那是另一篇文章的主题。现在我想向你分享今天就可以使用的 CLI 工具。

1、 execsnoop

从哪儿开始呢？如何查看新的进程。那些会消耗系统资源，但很短暂的进程，它们甚至不会出现在 top(1) 命令或其它工具中的显示之中。这些新进程可以使用 execsnoop 进行检测（或使用行业术语说，可以 被追踪 traced ）。 在追踪时，我将在另一个窗口中通过 SSH 登录：

# /usr/share/bcc/tools/execsnoop
PCOMM            PID    PPID   RET ARGS
sshd             12234  727      0 /usr/sbin/sshd -D -R
unix_chkpwd      12236  12234    0 /usr/sbin/unix_chkpwd root nonull
unix_chkpwd      12237  12234    0 /usr/sbin/unix_chkpwd root chkexpiry
bash             12239  12238    0 /bin/bash
id               12241  12240    0 /usr/bin/id -un
hostname         12243  12242    0 /usr/bin/hostname
pkg-config       12245  12244    0 /usr/bin/pkg-config --variable=completionsdir bash-completion
grepconf.sh      12246  12239    0 /usr/libexec/grepconf.sh -c
grep             12247  12246    0 /usr/bin/grep -qsi ^COLOR.*none /etc/GREP_COLORS
tty              12249  12248    0 /usr/bin/tty -s
tput             12250  12248    0 /usr/bin/tput colors
dircolors        12252  12251    0 /usr/bin/dircolors --sh /etc/DIR_COLORS
grep             12253  12239    0 /usr/bin/grep -qi ^COLOR.*none /etc/DIR_COLORS
grepconf.sh      12254  12239    0 /usr/libexec/grepconf.sh -c
grep             12255  12254    0 /usr/bin/grep -qsi ^COLOR.*none /etc/GREP_COLORS
grepconf.sh      12256  12239    0 /usr/libexec/grepconf.sh -c
grep             12257  12256    0 /usr/bin/grep -qsi ^COLOR.*none /etc/GREP_COLORS

哇哦。 那是什么？ 什么是 grepconf.sh？ 什么是 /etc/GREP_COLORS？ 是 grep 在读取它自己的配置文件……由 grep 运行的？ 这究竟是怎么工作的？

欢迎来到有趣的系统追踪世界。 你可以学到很多关于系统是如何工作的（或者根本不工作，在有些情况下），并且发现一些简单的优化方法。 execsnoop 通过跟踪 exec() 系统调用来工作，exec() 通常用于在新进程中加载不同的程序代码。

2、 opensnoop

接着上面继续，所以，grepconf.sh 可能是一个 shell 脚本，对吧？ 我将运行 file(1) 来检查它，并使用opensnoop bcc 工具来查看打开的文件：

# /usr/share/bcc/tools/opensnoop
PID    COMM               FD ERR PATH
12420  file                3   0 /etc/ld.so.cache
12420  file                3   0 /lib64/libmagic.so.1
12420  file                3   0 /lib64/libz.so.1
12420  file                3   0 /lib64/libc.so.6
12420  file                3   0 /usr/lib/locale/locale-archive
12420  file               -1   2 /etc/magic.mgc
12420  file                3   0 /etc/magic
12420  file                3   0 /usr/share/misc/magic.mgc
12420  file                3   0 /usr/lib64/gconv/gconv-modules.cache
12420  file                3   0 /usr/libexec/grepconf.sh
1      systemd            16   0 /proc/565/cgroup
1      systemd            16   0 /proc/536/cgroup

像 execsnoop 和 opensnoop 这样的工具会将每个事件打印一行。上图显示 file(1) 命令当前打开（或尝试打开）的文件：返回的文件描述符（“FD” 列）对于 /etc/magic.mgc 是 -1，而 “ERR” 列指示它是“文件未找到”。我不知道该文件，也不知道 file(1) 正在读取的 /usr/share/misc/magic.mgc 文件是什么。我不应该感到惊讶，但是 file(1) 在识别文件类型时没有问题：

# file /usr/share/misc/magic.mgc /etc/magic
/usr/share/misc/magic.mgc: magic binary file for file(1) cmd (version 14) (little endian)
/etc/magic:                magic text file for file(1) cmd, ASCII text

opensnoop 通过跟踪 open() 系统调用来工作。为什么不使用 strace -feopen file 命令呢？ 在这种情况下是可以的。然而，opensnoop 的一些优点在于它能在系统范围内工作，并且跟踪所有进程的 open() 系统调用。注意上例的输出中包括了从 systemd 打开的文件。opensnoop 应该系统开销更低：BPF 跟踪已经被优化过，而当前版本的 strace(1) 仍然使用较老和较慢的 ptrace(2) 接口。

3、 xfsslower

bcc/BPF 不仅仅可以分析系统调用。xfsslower 工具可以跟踪大于 1 毫秒（参数）延迟的常见 XFS 文件系统操作。

# /usr/share/bcc/tools/xfsslower 1
Tracing XFS operations slower than 1 ms
TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
14:17:34 systemd-journa 530    S 0       0           1.69 system.journal
14:17:35 auditd         651    S 0       0           2.43 audit.log
14:17:42 cksum          4167   R 52976   0           1.04 at
14:17:45 cksum          4168   R 53264   0           1.62 [
14:17:45 cksum          4168   R 65536   0           1.01 certutil
14:17:45 cksum          4168   R 65536   0           1.01 dir
14:17:45 cksum          4168   R 65536   0           1.17 dirmngr-client
14:17:46 cksum          4168   R 65536   0           1.06 grub2-file
14:17:46 cksum          4168   R 65536   128         1.01 grub2-fstest
[...]

在上图输出中，我捕获到了多个延迟超过 1 毫秒 的 cksum(1) 读取操作（字段 “T” 等于 “R”）。这是在 xfsslower 工具运行的时候，通过在 XFS 中动态地检测内核函数实现的，并当它结束的时候解除该检测。这个 bcc 工具也有其它文件系统的版本：ext4slower、btrfsslower、zfsslower 和 nfsslower。

这是个有用的工具，也是 BPF 追踪的重要例子。对文件系统性能的传统分析主要集中在块 I/O 统计信息 —— 通常你看到的是由 iostat(1) 工具输出，并由许多性能监视 GUI 绘制的图表。这些统计数据显示的是磁盘如何执行，而不是真正的文件系统如何执行。通常比起磁盘来说，你更关心的是文件系统的性能，因为应用程序是在文件系统中发起请求和等待。并且，文件系统的性能可能与磁盘的性能大为不同！文件系统可以完全从内存缓存中读取数据，也可以通过预读算法和回写缓存来填充缓存。xfsslower 显示了文件系统的性能 —— 这是应用程序直接体验到的性能。通常这对于排除整个存储子系统的问题是有用的；如果确实没有文件系统延迟，那么性能问题很可能是在别处。

4、 biolatency

虽然文件系统性能对于理解应用程序性能非常重要，但研究磁盘性能也是有好处的。当各种缓存技巧都无法挽救其延迟时，磁盘的低性能终会影响应用程序。 磁盘性能也是容量规划研究的目标。

iostat(1) 工具显示了平均磁盘 I/O 延迟，但平均值可能会引起误解。 以直方图的形式研究 I/O 延迟的分布是有用的，这可以通过使用 [biolatency] 来实现18：

# /usr/share/bcc/tools/biolatency
Tracing block device I/O... Hit Ctrl-C to end.
^C
     usecs               : count     distribution
         0 -> 1          : 0        |                                        |
         2 -> 3          : 0        |                                        |
         4 -> 7          : 0        |                                        |
         8 -> 15         : 0        |                                        |
        16 -> 31         : 0        |                                        |
        32 -> 63         : 1        |                                        |
        64 -> 127        : 63       |****                                    |
       128 -> 255        : 121      |*********                               |
       256 -> 511        : 483      |************************************    |
       512 -> 1023       : 532      |****************************************|
      1024 -> 2047       : 117      |********                                |
      2048 -> 4095       : 8        |                                        |

这是另一个有用的工具和例子；它使用一个名为 maps 的 BPF 特性，它可以用来实现高效的内核摘要统计。从内核层到用户层的数据传输仅仅是“计数”列。 用户级程序生成其余的。

值得注意的是，这种工具大多支持 CLI 选项和参数，如其使用信息所示：

# /usr/share/bcc/tools/biolatency -h
usage: biolatency [-h] [-T] [-Q] [-m] [-D] [interval] [count]

Summarize block device I/O latency as a histogram

positional arguments:
  interval            output interval, in seconds
  count               number of outputs

optional arguments:
  -h, --help          show this help message and exit
  -T, --timestamp     include timestamp on output
  -Q, --queued        include OS queued time in I/O time
  -m, --milliseconds  millisecond histogram
  -D, --disks         print a histogram per disk device

examples:
    ./biolatency            # summarize block I/O latency as a histogram
    ./biolatency 1 10       # print 1 second summaries, 10 times
    ./biolatency -mT 1      # 1s summaries, milliseconds, and timestamps
    ./biolatency -Q         # include OS queued time in I/O time
    ./biolatency -D         # show each disk device separately

它们的行为就像其它 Unix 工具一样，以利于采用而设计。

5、 tcplife

另一个有用的工具是 tcplife ，该例显示 TCP 会话的生命周期和吞吐量统计。

# /usr/share/bcc/tools/tcplife
PID   COMM       LADDR           LPORT RADDR           RPORT TX_KB RX_KB MS
12759 sshd       192.168.56.101  22    192.168.56.1    60639     2     3 1863.82
12783 sshd       192.168.56.101  22    192.168.56.1    60640     3     3 9174.53
12844 wget       10.0.2.15       34250 54.204.39.132   443      11  1870 5712.26
12851 curl       10.0.2.15       34252 54.204.39.132   443       0    74 505.90

在你说 “我不是可以只通过 tcpdump(8) 就能输出这个？” 之前请注意，运行 tcpdump(8) 或任何数据包嗅探器，在高数据包速率的系统上的开销会很大，即使 tcpdump(8) 的用户层和内核层机制已经过多年优化（要不可能更差）。tcplife 不会测试每个数据包；它只会有效地监视 TCP 会话状态的变化，并由此得到该会话的持续时间。它还使用已经跟踪了吞吐量的内核计数器，以及进程和命令信息（“PID” 和 “COMM” 列），这些对于 tcpdump(8) 等线上嗅探工具是做不到的。

6、 gethostlatency

之前的每个例子都涉及到内核跟踪，所以我至少需要一个用户级跟踪的例子。 这就是 gethostlatency，它检测用于名称解析的 gethostbyname(3) 和相关的库调用：

# /usr/share/bcc/tools/gethostlatency
TIME      PID    COMM                  LATms HOST
06:43:33  12903  curl                 188.98 opensource.com
06:43:36  12905  curl                   8.45 opensource.com
06:43:40  12907  curl                   6.55 opensource.com
06:43:44  12911  curl                   9.67 opensource.com
06:45:02  12948  curl                  19.66 opensource.cats
06:45:06  12950  curl                  18.37 opensource.cats
06:45:07  12952  curl                  13.64 opensource.cats
06:45:19  13139  curl                  13.10 opensource.cats

是的，总是有 DNS 请求，所以有一个工具来监视系统范围内的 DNS 请求会很方便（这只有在应用程序使用标准系统库时才有效）。看看我如何跟踪多个对 “opensource.com” 的查找？ 第一个是 188.98 毫秒，然后更快，不到 10 毫秒，毫无疑问，这是缓存的作用。它还追踪多个对 “opensource.cats” 的查找，一个不存在的可怜主机名，但我们仍然可以检查第一个和后续查找的延迟。（第二次查找后是否有一些否定缓存的影响？）

7、 trace

好的，再举一个例子。 trace 工具由 Sasha Goldshtein 提供，并提供了一些基本的 printf(1) 功能和自定义探针。 例如：

# /usr/share/bcc/tools/trace 'pam:pam_start "%s: %s", arg1, arg2'
PID    TID    COMM         FUNC             -
13266  13266  sshd         pam_start        sshd: root

在这里，我正在跟踪 libpam 及其 pam_start(3) 函数，并将其两个参数都打印为字符串。 libpam 用于插入式身份验证模块系统，该输出显示 sshd 为 “root” 用户调用了 pam_start()（我登录了）。 其使用信息中有更多的例子（trace -h），而且所有这些工具在 bcc 版本库中都有手册页和示例文件。 例如 trace_example.txt 和 trace.8。

通过包安装 bcc

安装 bcc 最佳的方法是从 iovisor 仓储库中安装，按照 bcc 的 INSTALL.md 进行即可。IO Visor 是包括了 bcc 的 Linux 基金会项目。4.x 系列 Linux 内核中增加了这些工具所使用的 BPF 增强功能，直到 4.9 添加了全部支持。这意味着拥有 4.8 内核的 Fedora 25 可以运行这些工具中的大部分。 使用 4.11 内核的 Fedora 26 可以全部运行它们（至少在目前是这样）。

如果你使用的是 Fedora 25（或者 Fedora 26，而且这个帖子已经在很多个月前发布了 —— 你好，来自遥远的过去！），那么这个通过包安装的方式是可以工作的。 如果您使用的是 Fedora 26，那么请跳至“通过源代码安装”部分，它避免了一个已修复的的已知错误。 这个错误修复目前还没有进入 Fedora 26 软件包的依赖关系。 我使用的系统是：

# uname -a
Linux localhost.localdomain 4.11.8-300.fc26.x86_64 #1 SMP Thu Jun 29 20:09:48 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
# cat /etc/fedora-release
Fedora release 26 (Twenty Six)

以下是我所遵循的安装步骤，但请参阅 INSTALL.md 获取更新的版本：

# echo -e '[iovisor]\nbaseurl=https://repo.iovisor.org/yum/nightly/f25/$basearch\nenabled=1\ngpgcheck=0' | sudo tee /etc/yum.repos.d/iovisor.repo
# dnf install bcc-tools
[...]
Total download size: 37 M
Installed size: 143 M
Is this ok [y/N]: y

安装完成后，您可以在 /usr/share 中看到新的工具：

# ls /usr/share/bcc/tools/
argdist       dcsnoop              killsnoop       softirqs    trace
bashreadline  dcstat               llcstat         solisten    ttysnoop
[...]

试着运行其中一个：

# /usr/share/bcc/tools/opensnoop
chdir(/lib/modules/4.11.8-300.fc26.x86_64/build): No such file or directory
Traceback (most recent call last):
  File "/usr/share/bcc/tools/opensnoop", line 126, in 
    b = BPF(text=bpf_text)
  File "/usr/lib/python3.6/site-packages/bcc/__init__.py", line 284, in __init__
    raise Exception("Failed to compile BPF module %s" % src_file)
Exception: Failed to compile BPF module

运行失败，提示 /lib/modules/4.11.8-300.fc26.x86_64/build 丢失。 如果你也遇到这个问题，那只是因为系统缺少内核头文件。 如果你看看这个文件指向什么（这是一个符号链接），然后使用 dnf whatprovides 来搜索它，它会告诉你接下来需要安装的包。 对于这个系统，它是：

# dnf install kernel-devel-4.11.8-300.fc26.x86_64
[...]
Total download size: 20 M
Installed size: 63 M
Is this ok [y/N]: y
[...]

现在：

# /usr/share/bcc/tools/opensnoop
PID    COMM               FD ERR PATH
11792  ls                  3   0 /etc/ld.so.cache
11792  ls                  3   0 /lib64/libselinux.so.1
11792  ls                  3   0 /lib64/libcap.so.2
11792  ls                  3   0 /lib64/libc.so.6
[...]

运行起来了。 这是捕获自另一个窗口中的 ls 命令活动。 请参阅前面的部分以使用其它有用的命令。

通过源码安装

如果您需要从源代码安装，您还可以在 INSTALL.md 中找到文档和更新说明。 我在 Fedora 26 上做了如下的事情：

sudo dnf install -y bison cmake ethtool flex git iperf libstdc++-static \
  python-netaddr python-pip gcc gcc-c++ make zlib-devel \
  elfutils-libelf-devel
sudo dnf install -y luajit luajit-devel  # for Lua support
sudo dnf install -y \
  http://pkgs.repoforge.org/netperf/netperf-2.6.0-1.el6.rf.x86_64.rpm
sudo pip install pyroute2
sudo dnf install -y clang clang-devel llvm llvm-devel llvm-static ncurses-devel

除 netperf 外一切妥当，其中有以下错误：

Curl error (28): Timeout was reached for http://pkgs.repoforge.org/netperf/netperf-2.6.0-1.el6.rf.x86_64.rpm [Connection timed out after 120002 milliseconds]

不必理会，netperf 是可选的，它只是用于测试，而 bcc 没有它也会编译成功。

以下是余下的 bcc 编译和安装步骤：

git clone https://github.com/iovisor/bcc.git
mkdir bcc/build; cd bcc/build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr
make
sudo make install

现在，命令应该可以工作了：

# /usr/share/bcc/tools/opensnoop
PID    COMM               FD ERR PATH
4131   date                3   0 /etc/ld.so.cache
4131   date                3   0 /lib64/libc.so.6
4131   date                3   0 /usr/lib/locale/locale-archive
4131   date                3   0 /etc/localtime
[...]

写在最后和其他的前端

这是一个可以在 Fedora 和 Red Hat 系列操作系统上使用的新 BPF 性能分析强大功能的快速浏览。我演示了 BPF 的流行前端 bcc ，并包括了其在 Fedora 上的安装说明。bcc 附带了 60 多个用于性能分析的新工具，这将帮助您充分利用 Linux 系统。也许你会直接通过 SSH 使用这些工具，或者一旦 GUI 监控程序支持 BPF 的话，你也可以通过它们来使用相同的功能。

此外，bcc 并不是正在开发的唯一前端。ply 和 bpftrace，旨在为快速编写自定义工具提供更高级的语言支持。此外，SystemTap 刚刚发布版本 3.2，包括一个早期的实验性 eBPF 后端。 如果这个继续开发，它将为运行多年来开发的许多 SystemTap 脚本和 tapset（库）提供一个安全和高效的生产级引擎。（随同 eBPF 使用 SystemTap 将是另一篇文章的主题。）

如果您需要开发自定义工具，那么也可以使用 bcc 来实现，尽管语言比 SystemTap、ply 或 bpftrace 要冗长得多。我的 bcc 工具可以作为代码示例，另外我还贡献了用 Python 开发 bcc 工具的教程。 我建议先学习 bcc 的 multi-tools，因为在需要编写新工具之前，你可能会从里面获得很多经验。 您可以从它们的 bcc 存储库funccount，funclatency，funcslower，stackcount，trace ，argdist 的示例文件中研究 bcc。

感谢 Opensource.com 进行编辑。

关于作者

Brendan Gregg 是 Netflix 的一名高级性能架构师，在那里他进行大规模的计算机性能设计、分析和调优。

via:https://opensource.com/article/17/11/bccbpf-performance

作者：Brendan Gregg 译者：yongshouzhang 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

本文作者 Brendan Gregg 目前是 Netflix 的高级性能架构师 ，他在那里做大规模计算机性能设计、分析和调优。他是《Systems Performance》等技术书的作者，因在系统管理员方面的成绩，获得过 2013年 USENIX LISA 大奖。他之前是 SUN 公司是性能领头人和内核工程师，研究存储和网络性能。他也发明和开发过一大波性能分析工具，很多已集成到操作系统中了 。

随着 BPF 追踪系统（基于时间采样）最后一个主要功能被合并至 Linux 4.9-rc1 版本的内核中，现在 Linux 内核拥有类似 DTrace 的原生追踪功能。DTrace 是 Solaris 系统中的高级追踪器。对于长期使用 DTrace 的用户和专家，这将是一个振奋人心的里程碑！现在在 Linux 系统上，你可以在生产环境中使用安全的、低负载的定制追踪系统，通过执行时间的柱状图和频率统计等信息，分析应用的性能以及内核。

用于 Linux 的追踪项目有很多，但是这个最终被合并进 Linux 内核的技术从一开始就根本不是一个追踪项目：它是最开始是用于 伯克利包过滤器 （ Berkeley Packet Filter ） （BPF）的增强功能。这些补丁允许 BPF 重定向数据包，从而创建软件定义网络（SDN）。久而久之，对事件追踪的支持就被添加进来了，使得程序追踪可用于 Linux 系统。

尽管目前 BPF 没有像 DTrace 一样的高级语言，但它所提供的前端已经足够让我创建很多 BPF 工具了，其中有些是基于我以前的 DTraceToolkit。这个帖子将告诉你怎么去用这些 BPF 提供的前端工具，以及畅谈这项技术将会何去何从。

示例

我已经将基于 BPF 的追踪工具添加到了开源的 bcc 项目里（感谢 PLUMgrid 公司的 Brenden Blanco 带领 bcc 项目的发展）。详见 bcc 安装 手册。它会在 /usr/share/bcc/tools 目录下添加一系列工具，包括接下来的那些工具。

捕获新进程：

# execsnoop
PCOMM            PID    RET ARGS
bash             15887    0 /usr/bin/man ls
preconv          15894    0 /usr/bin/preconv -e UTF-8
man              15896    0 /usr/bin/tbl
man              15897    0 /usr/bin/nroff -mandoc -rLL=169n -rLT=169n -Tutf8
man              15898    0 /usr/bin/pager -s
nroff            15900    0 /usr/bin/locale charmap
nroff            15901    0 /usr/bin/groff -mtty-char -Tutf8 -mandoc -rLL=169n -rLT=169n
groff            15902    0 /usr/bin/troff -mtty-char -mandoc -rLL=169n -rLT=169n -Tutf8
groff            15903    0 /usr/bin/grotty

硬盘 I/O 延迟的柱状图：

# biolatency -m
Tracing block device I/O... Hit Ctrl-C to end.
^C
     msecs           : count     distribution
       0 -> 1        : 96       |************************************  |
       2 -> 3        : 25       |*********                             |
       4 -> 7        : 29       |***********                           |
       8 -> 15       : 62       |***********************               |
      16 -> 31       : 100      |**************************************|
      32 -> 63       : 62       |***********************               |
      64 -> 127      : 18       |******                                |

追踪慢于 5 毫秒的 ext4 常见操作：

# ext4slower 5
Tracing ext4 operations slower than 5 ms
TIME     COMM           PID    T BYTES   OFF_KB   LAT(ms) FILENAME
21:49:45 supervise      3570   W 18      0           5.48 status.new
21:49:48 supervise      12770  R 128     0           7.55 run
21:49:48 run            12770  R 497     0          16.46 nsswitch.conf
21:49:48 run            12770  R 1680    0          17.42 netflix_environment.sh
21:49:48 run            12770  R 1079    0           9.53 service_functions.sh
21:49:48 run            12772  R 128     0          17.74 svstat
21:49:48 svstat         12772  R 18      0           8.67 status
21:49:48 run            12774  R 128     0          15.76 stat
21:49:48 run            12777  R 128     0           7.89 grep
21:49:48 run            12776  R 128     0           8.25 ps
21:49:48 run            12780  R 128     0          11.07 xargs
21:49:48 ps             12776  R 832     0          12.02 libprocps.so.4.0.0
21:49:48 run            12779  R 128     0          13.21 cut
[...]

追踪新建的 TCP 活跃连接（connect()）:

# tcpconnect
PID    COMM         IP SADDR            DADDR            DPORT
1479   telnet       4  127.0.0.1        127.0.0.1        23
1469   curl         4  10.201.219.236   54.245.105.25    80
1469   curl         4  10.201.219.236   54.67.101.145    80
1991   telnet       6  ::1              ::1              23
2015   ssh          6  fe80::2000:bff:fe82:3ac fe80::2000:bff:fe82:3ac 22

通过跟踪 getaddrinfo()/gethostbyname() 库的调用来追踪 DNS 延迟：

# gethostlatency
TIME      PID    COMM          LATms HOST
06:10:24  28011  wget          90.00 www.iovisor.org
06:10:28  28127  wget           0.00 www.iovisor.org
06:10:41  28404  wget           9.00 www.netflix.com
06:10:48  28544  curl          35.00 www.netflix.com.au
06:11:10  29054  curl          31.00 www.plumgrid.com
06:11:16  29195  curl           3.00 www.facebook.com
06:11:25  29404  curl          72.00 foo
06:11:28  29475  curl           1.00 foo

按类别划分 VFS 操作的时间间隔统计：

# vfsstat
TIME         READ/s  WRITE/s CREATE/s   OPEN/s  FSYNC/s
18:35:32:       231       12        4       98        0
18:35:33:       274       13        4      106        0
18:35:34:       586       86        4      251        0
18:35:35:       241       15        4       99        0

对一个给定的 PID，通过内核和用户堆栈轨迹来追踪 CPU 处理之外的时间（由内核进行统计）：

# offcputime -d -p 24347
Tracing off-CPU time (us) of PID 24347 by user + kernel stack... Hit Ctrl-C to end.
^C
[...]
    ffffffff810a9581 finish_task_switch
    ffffffff8185d385 schedule
    ffffffff81085672 do_wait
    ffffffff8108687b sys_wait4
    ffffffff81861bf6 entry_SYSCALL_64_fastpath
    --
    00007f6733a6b64a waitpid
    -                bash (24347)
        4952

    ffffffff810a9581 finish_task_switch
    ffffffff8185d385 schedule
    ffffffff81860c48 schedule_timeout
    ffffffff810c5672 wait_woken
    ffffffff8150715a n_tty_read
    ffffffff815010f2 tty_read
    ffffffff8122cd67 __vfs_read
    ffffffff8122df65 vfs_read
    ffffffff8122f465 sys_read
    ffffffff81861bf6 entry_SYSCALL_64_fastpath
    --
    00007f6733a969b0 read
    -                bash (24347)
        1450908

追踪 MySQL 查询延迟（通过 USDT 探针）：

# mysqld_qslower `pgrep -n mysqld`
Tracing MySQL server queries for PID 14371 slower than 1 ms...
TIME(s)        PID          MS QUERY
0.000000       18608   130.751 SELECT * FROM words WHERE word REGEXP '^bre.*n$'
2.921535       18608   130.590 SELECT * FROM words WHERE word REGEXP '^alex.*$'
4.603549       18608    24.164 SELECT COUNT(*) FROM words
9.733847       18608   130.936 SELECT count(*) AS count FROM words WHERE word REGEXP '^bre.*n$'
17.864776      18608   130.298 SELECT * FROM words WHERE word REGEXP '^bre.*n$' ORDER BY word

监测 pam 库并使用多种追踪工具观察登录请求：

# trace 'pam:pam_start "%s: %s", arg1, arg2'
TIME     PID    COMM         FUNC             -
17:49:45 5558   sshd         pam_start        sshd: root
17:49:47 5662   sudo         pam_start        sudo: root
17:49:49 5727   login        pam_start        login: bgregg

bcc 项目里的很多工具都有帮助信息（-h 选项），并且都应该包含有示例的 man 页面和文本文件。

必要性

2014 年，Linux 追踪程序就有一些内核相关的特性（来自 ftrace 和 pref_events），但是我们仍然要转储并报告进程数据，这种几十年前的老技术有很多的限制。你不能频繁地访问进程名、函数名、堆栈轨迹或内核中的任意的其它数据。你不能在将变量保存到一个监测事件里，又在另一个事件里访问它们，这意味着你不能在你需要的地方计算延迟（或者说时间增量）。你也不能创建一个内核内部的延迟柱状图，也不能追踪 USDT 探针，甚至不能写个自定义的程序。DTrace 可以做到所有这些，但仅限于 Solaris 或 BSD 系统。在 Linux 系统中，有些不在主线内核的追踪器，比如 SystemTap 就可以满足你的这些需求，但它也有自身的不足。（理论上说，你可以写一个基于探针的内核模块来满足需求-但实际上没人这么做。）

2014 年我加入了 Netflix cloud performance 团队。做了这么久的 DTrace 方面的专家，转到 Linux 对我来说简直不可思议。但我确实这么做了，而且遇到了巨大的挑战：在应用快速变化、采用微服务架构和分布式系统的情况下，调优 Netflix cloud。有时要用到系统追踪，而我之前是用的 DTrace。在 Linux 系统上可没有 DTrace，我就开始用 Linux 内核内建的 ftrace 和 perf_events 工具，构建了一个追踪工具（perf-tools）。这些工具很有用，但有些工作还是没法完成，尤其是延迟柱状图以及堆栈踪迹计数。我们需要的是内核追踪的可程序化。

发生了什么？

BPF 将程序化的功能添加到现有的内核追踪工具中（tracepoints、kprobes、uprobes）。在 Linux 4.x 系列的内核里，这些功能大大加强了。

时间采样是最主要的部分，它被 Linux 4.9-rc1 所采用（patchset）。十分感谢 Alexei Starovoitov（在 Facebook 致力于 BPF 的开发），他是这些 BPF 增强功能的主要开发者。

Linux 内核现在内建有以下这些特性（自 2.6 版本到 4.9 版本之间增加）：

• 内核级的动态追踪（BPF 对 kprobes 的支持）
• 用户级的动态追踪（BPF 对 uprobes 的支持）
• 内核级的静态追踪（BPF 对 tracepoints 的支持）
• 时间采样事件（BPF 的 pref_event_open）
• PMC 事件（BPF 的 pref_event_open）
• 过滤器（通过 BPF 程序）
• 调试输出（bpf_trace_printk()）
• 按事件输出（bpf_perf_event_output()）
• 基础变量（全局的和每个线程的变量，基于 BPF 映射）
• 关联数组（通过 BPF 映射）
• 频率计数（基于 BPF 映射）
• 柱状图（2 的冥次方、线性及自定义，基于 BPF 映射）
• 时间戳和时间增量（bpf_ktime_get_ns()，和 BPF 程序）
• 内核态的堆栈轨迹（BPF 栈映射）
• 用户态的堆栈轨迹 (BPF 栈映射)
• 重写 ring 缓存（pref_event_attr.write_backward）

我们采用的前端是 bcc，它同时提供 Python 和 lua 接口。bcc 添加了：

• 用户级静态追踪（基于 uprobes 的 USDT 探针）
• 调试输出（Python 中调用 BPF.trace_pipe() 和 BPF.trace_fields() 函数 ）
• 按事件输出（BPF_PERF_OUTPUT 宏和 BPF.open_perf_buffer()）
• 间隔输出（BPF.get_table() 和 table.clear()）
• 打印柱状图（table.print_log2_hist()）
• 内核级的 C 结构体导航（bcc 重写器映射到 bpf_probe_read() 函数）
• 内核级的符号解析（ksym()、 ksymaddr()）
• 用户级的符号解析（usymaddr()）
• BPF 跟踪点支持（通过 TRACEPOINT_PROBE）
• BPF 堆栈轨迹支持（包括针对堆栈框架的 walk 方法）
• 其它各种辅助宏和方法
• 例子（位于 /examples 目录）
• 工具（位于 /tools 目录）
• 教程（/docs/tutorial*.md）
• 参考手册（/docs/reference_guide.md）

直到最新也是最主要的特性被整合进来，我才开始写这篇文章，现在它在 4.9-rc1 内核中。我们还需要去完成一些次要的东西，还有另外一些事情要做，但是现在我们所拥有的已经值得欢呼了。现在 Linux 拥有了内建的高级追踪能力。

安全性

设计 BPF 及其增强功能时就考虑到生产环境级安全，它被用在大范围的生产环境里。不过你想的话，你还是可以找到一个挂起内核的方法。这种情况是偶然的，而不是必然，类似的漏洞会被快速修复，尤其是当 BPF 合并入了 Linux。因为 Linux 可是公众的焦点。

在开发过程中我们碰到了一些非 BPF 的漏洞，它们需要被修复：rcu 不可重入，这可能导致内核由于 funccount 挂起，在 4.6 内核版本中这个漏洞被 “bpf: map pre-alloc” 补丁集所修复，旧版本内核的漏洞 bcc 有个临时处理方案。还有一个是 uprobe 的内存计算问题，这导致 uprobe 分配内存失败，在 4.8 内核版本这个漏洞由 “uprobes: Fix the memcg accounting” 补丁所修复，并且该补丁还将被移植到之前版本的内核中（例如，它现在被移植到了 4.4.27 和 4.4.0-45.66 版本中）。

为什么 Linux 追踪用了这么久才加进来？

首要任务被分到了若干追踪器中间：这些不是某个追踪器单个的事情。想要了解更多关于这个或其它方面的问题，可以看一看我在 2014 年 tracing summit 上的讲话。我忽视了部分方案的反面影响：有些公司发现其它追踪器（SystemTap 和 LTTng）能满足他们的需求，尽管他们乐于听到 BPF 的开发进程，但考虑到他们现有的解决方案，帮助 BPF 的开发就不那么重要了。

BPF 仅在近两年里在追踪领域得到加强。这一过程原本可以更快的，但早期缺少全职从事于 BPF 追踪的工程师。Alexei Starovoitov (BPF 领导者)，Brenden Blanco (bcc 领导者)，我还有其它一些开发者，都有其它的事情要做。我在 Netflix 公司花了大量时间（志愿地），大概有 7% 的时间是花在 BPF 和 bcc 上。某种程度上这不是我的首要任务，因为我还有自己的工作（包括我的 perf-tools，一个可以工作在旧版本内核上的程序）。

现在BPF 追踪器已经推出了，已经有科技公司开始寻找会 BPF 的人了。但我还是推荐 Netflix 公司。（如果你为了 BPF 而要聘请我，那我还是十分乐于待在 Netflix 公司的！）

使用简单

DTrace 和 bcc/BPF 现在的最大区别就是哪个更好使用。这取决于你要用 BPF 追踪做什么了。如果你要

• 使用 BPF 工具/度量：应该是没什么区别的。工具的表现都差不多，图形用户界面都能取得类似度量指标。大部分用户通过这种方式使用 BPF。
• 开发工具/度量：bcc 的开发可难多了。DTrace 有一套自己的简单语言，D 语音，和 awk 语言相似，而 bcc 使用已有的语言（C 语言，Python 和 lua）及其类库。一个用 C 和 Python 写的 bcc 工具与仅仅用 D 语言写出来的工具相比，可能要多十多倍行数的代码，或者更多。但是很多 DTrace 工具用 shell 封装来提供参数和差错检查，会让代码变得十分臃肿。编程的难处是不同的：重写 bcc 更需要巧妙性，这导致某些脚本更加难开发。（尤其是 bpf_probe_read() 这类的函数，需要了解更多 BPF 的内涵知识）。当计划改进 bcc 时，这一情形将得到改善。
• 运行常见的命令：十分相近。通过 dtrace 命令，DTrace 能做很多事，但 bcc 有各种工具，trace、argdist、funccount、funclatency 等等。
• 编写自定义的特殊命令：使用 DTrace 的话，这就没有必要了。允许定制消息快速传递和系统快速响应，DTrace 的高级分析很快。而 bcc 现在受限于它的多种工具以及它们的适用范围。

简单来说，如果你只使用 BPF 工具的话，就不必关注这些差异了。如果你经验丰富，是个开发者（像我一样），目前 bcc 的使用更难一些。

举一个 bcc 的 Python 前端的例子，下面是追踪硬盘 I/O 并打印出 I/O 大小的柱状图代码：

from bcc import BPF
from time import sleep

# load BPF program
b = BPF(text="""
#include <uapi/linux/ptrace.h>
#include <linux/blkdev.h>

BPF_HISTOGRAM(dist);

int kprobe__blk_account_io_completion(struct pt_regs *ctx, struct request *req)
{
    dist.increment(bpf_log2l(req->__data_len / 1024));
    return 0;
}
""")

# header
print("Tracing... Hit Ctrl-C to end.")

# trace until Ctrl-C
try:
    sleep(99999999)
except KeyboardInterrupt:
    print

# output
b["dist"].print_log2_hist("kbytes")

注意 Python 代码中嵌入的 C 语句（text=）。

这就完成了任务，但仍有改进的空间。好在我们有时间去做：人们使用 Linux 4.9 并能用上 BPF 还得好几个月呢，所以我们有时间来制造工具和前端。

高级语言

前端越简单，比如高级语言，所改进的可能就越不如你所期望的。绝大多数人使用封装好的工具（和图形界面），仅有少部分人能写出这些工具。但我不反对使用高级语言，比如 SystemTap，毕竟已经开发出来了。

#!/usr/bin/stap
/*
 * opensnoop.stp    Trace file open()s.  Basic version of opensnoop.
 */

probe begin
{
    printf("\n%6s %6s %16s %s\n", "UID", "PID", "COMM", "PATH");
}

probe syscall.open
{
    printf("%6d %6d %16s %s\n", uid(), pid(), execname(), filename);
}

如果拥有整合了语言和脚本的 SystemTap 前端与高性能的内置在内核中的 BPF 后端，会不会令人满意呢？RedHat 公司的 Richard Henderson 已经在进行相关工作了，并且发布了 初代版本！

这是 ply，一个完全新颖的 BPF 高级语言：

#!/usr/bin/env ply

kprobe:SyS_*
{
    $syscalls[func].count()
}

这也是一份承诺。

尽管如此，我认为工具开发者的实际难题不是使用什么语言：而是要了解要用这些强大的工具做什么？

如何帮助我们

• 推广：BPF 追踪器目前还没有什么市场方面的进展。尽管有公司了解并在使用它（Facebook、Netflix、Github 和其它公司），但要广为人知尚需时日。你可以分享关于 BPF 的文章和资源给业内的其它公司来帮助我们。
• 教育：你可以撰写文章，发表演讲，甚至参与 bcc 文档的编写。分享 BPF 如何解决实际问题以及为公司带来收益的实例。
• 解决 bcc 的问题：参考 bcc issue list，这包含了错误和需要的特性。
• 提交错误：使用 bcc/BPF，提交你发现的错误。
• 创造工具：有很多可视化的工具需要开发，但请不要太草率，因为大家会先花几个小时学习使用你做的工具，所以请尽量把工具做的直观好用（参考我的文档）。就像 Mike Muuss 提及到他自己的 ping 程序：“要是我早知道这是我一生中最出名的成就，我就多开发一两天，添加更多选项。”
• 高级语言：如果现有的 bcc 前端语言让你很困扰，或许你能弄门更好的语言。要是你想将这门语言内建到 bcc 里面，你需要使用 libbcc。或者你可以帮助 SystemTap BPF 或 ply 的工作。
• 整合图形界面：除了 bcc 可以使用的 CLI 命令行工具，怎么让这些信息可视呢？延迟热点图，火焰图等等。

其它追踪器

那么 SystemTap、ktap、sysdig、LTTng 等追踪器怎么样呢？它们有个共同点，要么使用了 BPF，要么在自己的领域做得更好。会有单独的文章介绍它们自己。

至于 DTrace ？我们公司目前还在基于 FreeBSD 系统的 CDN 中使用它。

更多 bcc/BPF 的信息

我已经写了一篇《bcc/BPF 工具最终用户教程》，一篇《bcc Python 开发者教程》，一篇《bcc/BPF 参考手册》，并提供了一些有用的工具，每一个工具都有一个 example.txt 文件和 man page。我之前写过的关于 bcc 和 BPF 的文章有：

• eBPF: One Small Step （后来就叫做 BPF）
• bcc: Taming Linux 4.3+ Tracing Superpowers
• Linux eBPF Stack Trace Hack （现在官方支持追踪堆栈了）
• Linux eBPF Off-CPU Flame Graph
• Linux Wakeup and Off-Wake Profiling
• Linux Chain Graph Prototype
• Linux eBPF/bcc uprobes
• Linux BPF Superpowers
• Ubuntu Xenial bcc/BPF
• Linux bcc Tracing Security Capabilities
• Linux MySQL Slow Query Tracing with bcc/BPF
• Linux bcc ext4 Latency Tracing
• Linux bcc/BPF Run Queue (Scheduler) Latency
• Linux bcc/BPF Node.js USDT Tracing
• Linux bcc tcptop
• Linux 4.9's Efficient BPF-based Profiler

我在 Facebook 的 Performance@Scale Linux BPF Superpowers 大会上发表过一次演讲。十二月份，我将在 Boston 发表关于 BPF/bcc 在 USENIX LISA 方面的演讲和教程。

致谢

• Van Jacobson 和 Steve McCanne，他们创建了最初用作过滤器的 BPF 。
• Barton P. Miller，Jeffrey K. Hollingsworth，and Jon Cargille，发明了动态追踪，并发表论文《Dynamic Program Instrumentation for Scalable Performance Tools》，可扩展高性能计算协议 （SHPCC），于田纳西州诺克斯维尔市，1994 年 5 月发表。
• kerninst (ParaDyn, UW-Madison)，展示了动态跟踪的价值的早期动态跟踪工具（上世纪 90 年代后期）
• Mathieu Desnoyers (在 LTTng)，内核的主要开发者，主导 tracepoints 项目。
• IBM 开发的作为 DProbes 一部分的 kprobes，DProbes 在 2000 年时曾与 LTT 一起提供 Linux 动态追踪，但没有整合到一起。
• Bryan Cantrill, Mike Shapiro, and Adam Leventhal (Sun Microsystems)，DTrace 的核心开发者，DTrace 是一款很棒的动态追踪工具，安全而且简单（2004 年）。对于动态追踪技术，DTrace 是科技的重要转折点：它很安全，默认安装在 Solaris 以及其它以可靠性著称的系统里。
• 来自 Sun Microsystems 的各部门的许多员工，促进了 DTrace，为我们带来了高级系统追踪的意识。
• Roland McGrath (在 Red Hat)，utrace 项目的主要开发者，utrace 变成了后来的 uprobes。
• Alexei Starovoitov (PLUMgrid， 后来是 Facebook)，加强版 BPF（可编程内核部件）的主要开发者。
• 那些帮助反馈、提交代码、测试以及针对增强版 BPF 补丁（请在 lkml 搜索 BPF）的 Linux 内核工程师： Wang Nan、 Daniel Borkmann、 David S. Miller、 Peter Zijlstra 以及其它很多人。
• Brenden Blanco (PLUMgrid)，bcc 的主要开发者。
• Sasha Goldshtein (Sela) 开发了 bcc 中的跟踪点支持，和功能最强大的 bcc 工具 trace 及 argdist，帮助 USDT 项目的开发。
• Vicent Martí 和其它 Github 上的工程师，为 bcc 编写了基于 lua 的前端，帮助 USDT 部分项目的开发。
• Allan McAleavy、 Mark Drayton，和其他的改进 bcc 的贡献者。

感觉 Netflix 提供的环境和支持，让我能够编写 BPF 和 bcc 跟踪器并完成它们。我已经编写了多年的追踪工具（使用 TNF/prex、DTrace、SystemTap、ktap、ftrace、perf，现在是 bcc/BPF），并写书、博客以及评论，

最后，感谢 Deirdré 编辑了另外一篇文章。

总结

Linux 没有 DTrace（语言），但它现在有了，或者说拥有了 DTraceTookit（工具）。

通过增强内置的 BPF 引擎，Linux 4.9 内核拥有了用来支持现代化追踪的最后一项能力。内核支持这一最难的部分已经做完了。今后的任务包括更多的命令行执行工具，以及高级语言和图形用户界面。

对于性能分析产品的客户，这也是一件好事：你能查看延迟柱状图和热点图，CPU 处理和 CPU 之外的火焰图，拥有更好的时延断点和更低耗的工具。在用户空间按包跟踪和处理是没有效率的方式。

那么你什么时候会升级到 Linux 4.9 呢？一旦官方发布，新的性能测试工具就来了：apt-get install bcc-tools 。

开始享受它吧!

Brendan

via: http://www.brendangregg.com/blog/2016-10-27/dtrace-for-linux-2016.html

作者：Brendan Gregg 译者：GitFuture 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出