xinyin025/learn.lianglianglee.com
1
0
Fork 0
mirror of https://github.com/zhwei820/learn.lianglianglee.com.git synced 2025-11-15 05:33:49 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

u

Browse Source
This commit is contained in:
周伟
2022-05-11 19:04:14 +08:00
parent 9440ac7291
commit d9c5ffd627
826 changed files with 0 additions and 481675 deletions
Download Patch File Download Diff File Expand all files Collapse all files

396
专栏/容器实战高手课/加餐06 BCC：入门eBPF的前端工具.md.html
View File

@@ -25,13 +25,7 @@
<meta name="generator" content="Hexo 4.2.0">
</head>
<body>
<div class="book-container">
<div class="book-sidebar">
@@ -55,385 +49,196 @@
<li><a href="/" class="current-tab">首页</a></li>
</ul>
<ul class="uncollapsible">
<li><a href="../">上一级</a></li>
</ul>
<ul class="uncollapsible">
<li>
<a href="/专栏/容器实战高手课/00 开篇词 一个态度两个步骤，成为容器实战高手.md.html">00 开篇词 一个态度两个步骤，成为容器实战高手.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/01 认识容器：容器的基本操作和实现原理.md.html">01 认识容器：容器的基本操作和实现原理.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/02 理解进程（1）：为什么我在容器中不能kill 1号进程？.md.html">02 理解进程（1）：为什么我在容器中不能kill 1号进程？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/03 理解进程（2）：为什么我的容器里有这么多僵尸进程？.md.html">03 理解进程（2）：为什么我的容器里有这么多僵尸进程？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/04 理解进程（3）：为什么我在容器中的进程被强制杀死了？.md.html">04 理解进程（3）：为什么我在容器中的进程被强制杀死了？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/05 容器CPU（1）：怎么限制容器的CPU使用？.md.html">05 容器CPU（1）：怎么限制容器的CPU使用？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/06 容器CPU（2）：如何正确地拿到容器CPU的开销？.md.html">06 容器CPU（2）：如何正确地拿到容器CPU的开销？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/07 Load Average：加了CPU Cgroup限制，为什么我的容器还是很慢？.md.html">07 Load Average：加了CPU Cgroup限制，为什么我的容器还是很慢？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/08 容器内存：我的容器为什么被杀了？.md.html">08 容器内存：我的容器为什么被杀了？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/09 Page Cache：为什么我的容器内存使用量总是在临界点.md.html">09 Page Cache：为什么我的容器内存使用量总是在临界点.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/10 Swap：容器可以使用Swap空间吗？.md.html">10 Swap：容器可以使用Swap空间吗？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/11 容器文件系统：我在容器中读写文件怎么变慢了.md.html">11 容器文件系统：我在容器中读写文件怎么变慢了.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/12 容器文件Quota：容器为什么把宿主机的磁盘写满了？.md.html">12 容器文件Quota：容器为什么把宿主机的磁盘写满了？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/13 容器磁盘限速：我的容器里磁盘读写为什么不稳定.md.html">13 容器磁盘限速：我的容器里磁盘读写为什么不稳定.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/14 容器中的内存与IO：容器写文件的延时为什么波动很大？.md.html">14 容器中的内存与IO：容器写文件的延时为什么波动很大？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/15 容器网络：我修改了procsysnet下的参数，为什么在容器中不起效？.md.html">15 容器网络：我修改了procsysnet下的参数，为什么在容器中不起效？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/16 容器网络配置（1）：容器网络不通了要怎么调试.md.html">16 容器网络配置（1）：容器网络不通了要怎么调试.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/17 容器网络配置（2）：容器网络延时要比宿主机上的高吗.md.html">17 容器网络配置（2）：容器网络延时要比宿主机上的高吗.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/18 容器网络配置（3）：容器中的网络乱序包怎么这么高？.md.html">18 容器网络配置（3）：容器中的网络乱序包怎么这么高？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/19 容器安全（1）：我的容器真的需要privileged权限吗.md.html">19 容器安全（1）：我的容器真的需要privileged权限吗.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/20 容器安全（2）：在容器中，我不以root用户来运行程序可以吗？.md.html">20 容器安全（2）：在容器中，我不以root用户来运行程序可以吗？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/加餐01 案例分析：怎么解决海量IPVS规则带来的网络延时抖动问题？.md.html">加餐01 案例分析：怎么解决海量IPVS规则带来的网络延时抖动问题？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/加餐02 理解perf：怎么用perf聚焦热点函数？.md.html">加餐02 理解perf：怎么用perf聚焦热点函数？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/加餐03 理解ftrace（1）：怎么应用ftrace查看长延时内核函数？.md.html">加餐03 理解ftrace（1）：怎么应用ftrace查看长延时内核函数？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/加餐04 理解ftrace（2）：怎么理解ftrace背后的技术tracepoint和kprobe？.md.html">加餐04 理解ftrace（2）：怎么理解ftrace背后的技术tracepoint和kprobe？.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/加餐05 eBPF：怎么更加深入地查看内核中的函数？.md.html">加餐05 eBPF：怎么更加深入地查看内核中的函数？.md.html</a>
</li>
<li>
<a class="current-tab" href="/专栏/容器实战高手课/加餐06 BCC：入门eBPF的前端工具.md.html">加餐06 BCC：入门eBPF的前端工具.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/加餐福利 课后思考题答案合集.md.html">加餐福利 课后思考题答案合集.md.html</a>
</li>
<li>
<a href="/专栏/容器实战高手课/结束语 跳出舒适区，突破思考的惰性.md.html">结束语 跳出舒适区，突破思考的惰性.md.html</a>
</li>
</ul>
</div>
</div>
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
<div class="sidebar-toggle-inner"></div>
</div>
<script>
function add_inner() {
@@ -443,9 +248,6 @@
inner.classList.add('show')
}
function remove_inner() {
let inner = document.querySelector('.sidebar-toggle-inner')
@@ -453,9 +255,6 @@
inner.classList.remove('show')
}
function sidebar_toggle() {
let sidebar_toggle = document.querySelector('.sidebar-toggle')
@@ -485,9 +284,6 @@
}
function open_sidebar() {
let sidebar = document.querySelector('.book-sidebar')
@@ -511,13 +307,7 @@ function hide_canvas() {
overlay.classList.remove('show')
}
</script>
<div class="off-canvas-content">
<div class="columns">
@@ -579,13 +369,7 @@ function hide_canvas() {
<pre><code># apt install bpfcc-tools
``
安装完 BCC 软件包之后，你在 Linux 系统上就会看到多了 100 多个 BCC 的小工具 （在 Ubuntu 里，这些工具的名字后面都加了 bpfcc 的后缀）：
</code></pre>
<h1>ls -l /sbin/*-bpfcc | more</h1>
@@ -647,29 +431,11 @@ function hide_canvas() {
<pre><code>
这些工具几乎覆盖了 Linux 内核中各个模块，它们可以对 Linux 某个模块做最基本的 profile。你可以看看下面这张图，图里把 BCC 的工具与 Linux 中的各个模块做了一个映射。
![img](assets/eb90017c78byyyy5399d275fe63783db.png)
在 BCC 的 github repo 里，也有很完整的文档和例子来描述每一个工具。Brendan D. Gregg写了一本书，书名叫《BPF Performance Tools》（我们上一讲也提到过这本书），这本书从 Linux CPU/Memory/Filesystem/Disk/Networking 等角度介绍了如何使用 BCC 工具，感兴趣的你可以自行学习。
为了让你更容易理解，这里我给你举两个例子。
第一个是使用 opensnoop 工具，用它来监控节点上所有打开文件的操作。这个命令有时候也可以用来查看某个文件被哪个进程给动过。
比如说，我们先启动 opensnoop，然后在其他的 console 里运行 touch test-open 命令，这时候我们就会看到 touch 命令在启动时读取到的库文件和配置文件，以及最后建立的“test-open”这个文件。
</code></pre>
<h1>opensnoop-bpfcc</h1>
@@ -717,17 +483,8 @@ function hide_canvas() {
<pre><code>
第二个是使用 softirqs 这个命令，查看节点上各种类型的 softirqs 花费时间的分布图 （直方图模式）。
比如在下面这个例子里，每一次 timer softirq 执行时间在 0～1us 时间区间里的有 16 次，在 2-3us 时间区间里的有 49 次，以此类推。
在我们分析网络延时的时候，也用过这个 softirqs 工具，用它来确认 timer softirq 花费的时间。
</code></pre>
<h1>softirqs-bpfcc -d</h1>
@@ -809,37 +566,13 @@ usecs : count distribution
<pre><code>
BCC 中的工具数目虽然很多，但是你用过之后就会发现，它们的输出模式基本上就是上面我说的这两种。
第一种类似事件模式，就像 opensnoop 的输出一样，发生一次就输出一次；第二种是直方图模式，就是把内核中执行函数的时间做个统计，然后用直方图的方式输出，也就是 softirqs -d 的执行结果。
用过 BCC 工具之后，我们再来看一下 BCC 工具的工作原理，这样以后你有需要的时候，自己也可以编写和部署一个 BCC 工具了。
## BCC 的工作原理
让我们来先看一下 BCC 工具的代码结构。
因为目前 BCC 的工具都是用 python 写的，所以你直接可以用文本编辑器打开节点上的一个工具文件。比如打开 /sbin/opensnoop-bpfcc 文件（也可在 github bcc 项目中查看 opensnoop.py），这里你可以看到大概 200 行左右的代码，代码主要分成了两部分。
第一部分其实是一块 C 代码，里面定义的就是 eBPF 内核态的代码，不过它是以 python 字符串的形式加在代码中的。
我在下面列出了这段 C 程序的主干，其实就是定义两个 eBPF Maps 和两个 eBPF Programs 的函数：
</code></pre>
<h1>define BPF program</h1>
@@ -879,9 +612,6 @@ BPF_PERF_OUTPUT(events); // BPF_MAP_TYPE_PERF_EVENT_ARRAY</p>
<pre><code>
第二部分就是用 python 写的用户态代码，它的作用是加载内核态 eBPF 的代码，把内核态的函数 trace_entry() 以 kprobe 方式挂载到内核函数 do_sys_open()，把 trace_return() 以 kproberet 方式也挂载到 do_sys_open()，然后从 eBPF Maps 里读取数据并且输出。
</code></pre>
<p>…</p>
@@ -917,13 +647,7 @@ exit()
<pre><code>
从代码的结构看，其实这和我们上一讲介绍的 eBPF 标准的编程模式是差不多的，只是用户态的程序是用 python 来写的。不过这里有一点比较特殊，用户态在加载程序的时候，输入的是 C 程序的文本而不是 eBPF bytecode。
BCC 可以这么做，是因为它通过 pythonBPF() 加载 C 代码之后，调用 libbcc 库中的函数 bpf_module_create_c_from_string() 把 C 代码编译成了 eBPF bytecode。也就是说，libbcc 库中集成了 clang/llvm 的编译器。
</code></pre>
<pre><code>def __init__(self, src_file=b&quot;&quot;, hdr_file=b&quot;&quot;, text=None, debug=0,
@@ -943,53 +667,17 @@ self.module = lib.bpf_module_create_c_from_string(text, self.debug，cflags_arra
<pre><code>
我们弄明白 libbcc 库的作用之后，再来整体看一下 BCC 工具的工作方式。为了让你理解，我给你画了一张示意图：
![img](assets/94b146c3f35ca0b9aa04c32f29fdf572.jpeg)
BCC 的这种设计思想是为了方便 eBPF 程序的开发和使用，特别是 eBPF 内核态的代码对当前运行的内核版本是有依赖的，比如在 4.15 内核的节点上编译好的 bytecode，放到 5.4 内核的节点上很有可能是运行不了的。
那么让编译和运行都在同一个节点，出现问题就可以直接修改源代码文件了。你有没有发现，这么做有点像把 C 程序的处理当成 python 的处理方式。
BCC 的这种设计思想虽然有好处，但是也带来了问题。其实问题也是很明显的，首先我们需要在运行 BCC 工具的节点上必须安装内核头文件，这个在编译内核态 eBPF C 代码的时候是必须要做的。
其次，在 libbcc 的库里面包含了 clang/llvm 的编译器，这不光占用磁盘空间，在运行程序前还需要编译，也会占用节点的 CPU 和 Memory，同时也让 BCC 工具的启动时间变长。这两个问题都会影响到 BCC 生产环境中的使用。
## BCC 工具的发展
那么我们有什么办法来解决刚才说的问题呢？eBPF 的技术在不断进步，最新的 BPF CO-RE 技术可以解决这个问题。我们下面就来看 BPF CO-RE 是什么意思。
CO-RE 是“Compile Once – Run Everywhere”的缩写，BPF CO-RE 通过对 Linux 内核、用户态 BPF loader（libbpf 库）以及 Clang 编译器的修改，来实现编译出来的 eBPF 程序可以在不同版本的内核上运行。
不同版本的内核上，用 CO-RE 编译出来的 eBPF 程序都可以运行。在 Linux 内核和 BPF 程序之间，会通过BTF（BPF Type Format）来协调不同版本内核中数据结构的变量偏移或者变量长度变化等问题。
在 BCC 的 github repo 里，有一个目录libbpf-tools，在这个目录下已经有一些重写过的 BCC 工具的源代码，它们并不是用 python+libbcc 的方式实现的，而是用到了 libbpf+BPF CO-RE 的方式。
如果你的系统上有高于版本 10 的 CLANG/LLVM 编译器，就可以尝试编译一下 libbpf-tools 下的工具。这里可以加一个“V=1”参数，这样我们就能清楚编译的步骤了。
</code></pre>
<h1>git remote -v</h1>
@@ -1037,17 +725,8 @@ cc -g -O2 -Wall .output/opensnoop.o /root/bcc/libbpf-tools/.output/libbpf.a .out
<pre><code>
我们梳理一下编译的过程。首先这段代码生成了 libbpf.a 这个静态库，然后逐个的编译每一个工具。对于每一个工具的代码结构是差不多的，编译的方法也是差不多的。
我们拿 opensnoop 做例子来看一下，它的源代码分为两个文件。opensnoop.bpf.c 是内核态的 eBPF 代码，opensnoop.c 是用户态的代码，这个和我们之前学习的 eBPF 代码的标准结构是一样的。主要不同点有下面这些。
内核态的代码不再逐个 include 内核代码的头文件，而是只要 include 一个“vmlinux.h”就可以。在“vmlinux.h”中包含了所有内核的数据结构，它是由内核文件 vmlinux 中的 BTF 信息转化而来的。
</code></pre>
<h1>cat opensnoop.bpf.c | head</h1>
@@ -1071,9 +750,6 @@ cc -g -O2 -Wall .output/opensnoop.o /root/bcc/libbpf-tools/.output/libbpf.a .out
<pre><code>
我们使用bpftool这个工具，可以把编译出来的 opensnoop.bpf.o 重新生成为一个 C 语言的头文件 opensnoop.skel.h。这个头文件中定义了加载 eBPF 程序的函数，eBPF bytecode 的二进制流也直接写在了这个头文件中。
</code></pre>
<p>bin/bpftool gen skeleton .output/opensnoop.bpf.o &gt; .output/opensnoop.skel.h</p>
@@ -1081,13 +757,7 @@ cc -g -O2 -Wall .output/opensnoop.o /root/bcc/libbpf-tools/.output/libbpf.a .out
<pre><code>
用户态的代码 opensnoop.c 直接 include 这个 opensnoop.skel.h，并且调用里面的 eBPF 加载的函数。这样在编译出来的可执行程序 opensnoop，就可以直接运行了，不用再找 eBPF bytecode 文件或者 eBPF 内核态的 C 文件。并且这个 opensnoop 程序可以运行在不同版本内核的节点上（当然，这个内核需要打开 CONFIG_DEBUG_INFO_BTF 这个编译选项）。
比如，我们可以把在 kernel5.4 节点上编译好的 opensnoop 程序 copy 到一台 kernel5.10.4 的节点来运行：
</code></pre>
<h1>uname -r</h1>
@@ -1109,61 +779,19 @@ cc -g -O2 -Wall .output/opensnoop.o /root/bcc/libbpf-tools/.output/libbpf.a .out
<pre><code>
从上面的代码我们会发现，这时候的 opensnoop 不依赖任何的库函数，只有一个文件，strip 后的文件大小只有 235KB，启动运行的时候，既不不需要读取外部的文件，也不会做额外的编译。
## 重点小结
好了，今天我们主要讲了 eBPF 的一个前端工具 BCC，我来给你总结一下。
在我看来，对于把 eBPF 运用于 Linux 内核的性能分析和跟踪调试这个领域，BCC 是社区中最有影响力的一个项目。BCC 项目提供了 eBPF 工具开发的 Python/Lua/C++ 的接口，以及上百个基于 eBPF 的工具。
对不熟悉 eBPF 的同学来说，可以直接拿这些工具来调试 Linux 系统中的问题。而对于了解 eBPF 的同学，也可以利用 BCC 提供的接口，开发自己需要的 eBPF 工具。
BCC 工具目前主要通过 ptyhon+libbcc 的模式在目标节点上运行，但是这个模式需要节点有内核头文件以及内嵌在 libbcc 中的 Clang/LLVM 编译器，每次程序启动的时候还需要再做一次编译。
为了弥补这个缺点，BCC 工具开始向 libbpf+BPF CO-RE 的模式转变。用这种新模式编译出来的 BCC 工具程序，只需要很少的系统资源就可以在目标节点上运行，并且不受内核版本的限制。
除了 BCC 之外，你还可以看一下bpftrace、ebpf-exporter等 eBPF 的前端工具。
bpftrace 提供了类似 awk 和 C 语言混合的一种语言，在使用时也很类似 awk，可以用一两行的命令来完成一次 eBPF 的调用，它能做一些简单的内核事件的跟踪。当然它也可以编写比较复杂的 eBPF 程序。
ebpf-exporter 可以把 eBPF 程序收集到的 metrics 以Prometheus的格式对外输出，然后通过Grafana的 dashboard，可以对内核事件做长期的以及更加直观的监控。
总之，前面提到的这些工具，你都可以好好研究一下，它们可以帮助你对容器云平台上的节点做内核级别的监控与诊断。
## 思考题
这一讲的最后，我给你留一道思考题吧。
你可以动手操作一下，尝试编译和运行 BCC 项目中libbpf-tools目录下的工具。
欢迎你在留言区记录你的心得或者疑问。如果这一讲对你有帮助，也欢迎分享给你的同事、朋友，和他一起学习进步。
</code></pre>
@@ -1187,9 +815,6 @@ ebpf-exporter 可以把 eBPF 程序收集到的 metrics 以Prometheus的格式
</div>
</div>
</div>
</div>
@@ -1197,9 +822,6 @@ ebpf-exporter 可以把 eBPF 程序收集到的 metrics 以Prometheus的格式
</div>
</div>
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
</div>
@@ -1215,17 +837,11 @@ ebpf-exporter 可以把 eBPF 程序收集到的 metrics 以Prometheus的格式
<script>
window.dataLayer = window.dataLayer || [];
function gtag() {
dataLayer.push(arguments);
}
gtag('js', new Date());
gtag('config', 'G-NPSEEVD756');
@@ -1251,9 +867,6 @@ ebpf-exporter 可以把 eBPF 程序收集到的 metrics 以Prometheus的格式
setCookie("lastPath", path)
}
function setCookie(cname, cvalue) {
var d = new Date();
@@ -1265,9 +878,6 @@ ebpf-exporter 可以把 eBPF 程序收集到的 metrics 以Prometheus的格式
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
}
function getCookie(cname) {
var name = cname + "=";
@@ -1285,12 +895,6 @@ ebpf-exporter 可以把 eBPF 程序收集到的 metrics 以Prometheus的格式
return "";
}
</script>
</html>