?

由范老師和我一起翻譯的圖書 《Linux內核觀測技術BPF》 已經在 JD 上有現貨，歡迎感興趣 BPF 技術的同學選購。鏈接地址?https://item.jd.com/72110825905.html

“eBPF 是我見過的 Linux 中最神奇的技術，沒有之一，已成為 Linux 內核中頂級子模塊，從 tcpdump 中用作網絡包過濾的經典 cbpf，到成為通用 Linux 內核技術的 eBPF，已經完成華麗蛻變，為應用與神奇的內核打造了一座橋梁，在系統跟蹤、觀測、性能調優、安全和網絡等領域發揮重要的角色。為 Service Mesh 打造了具備 API 感知和安全高效的容器網絡方案 Cilium，其底層正是基于 eBPF 技術”

1. BPF

BPF（Berkeley Packet Filter ），中文翻譯為伯克利包過濾器，是類 Unix 系統上數據鏈路層的一種原始接口，提供原始鏈路層封包的收發。1992 年，Steven McCanne 和 Van Jacobson 寫了一篇名為《BSD數據包過濾：一種新的用戶級包捕獲架構》的論文。在文中，作者描述了他們如何在 Unix 內核實現網絡數據包過濾，這種新的技術比當時最先進的數據包過濾技術快 20 倍。BPF 在數據包過濾上引入了兩大革新：

• 一個新的虛擬機 (VM) 設計，可以有效地工作在基于寄存器結構的 CPU 之上；

• 應用程序使用緩存只復制與過濾數據包相關的數據，不會復制數據包的所有信息。這樣可以最大程度地減少BPF 處理的數據；

由于這些巨大的改進，所有的 Unix 系統都選擇采用 BPF 作為網絡數據包過濾技術，直到今天，許多 Unix 內核的派生系統中（包括 Linux 內核）仍使用該實現。

tcpdump 的底層采用 BPF 作為底層包過濾技術，我們可以在命令后面增加 ”-d“ 來查看 tcpdump 過濾條件的底層匯編指令。

$ tcpdump -d 'ip and tcp port 8080'
(000) ldh      [12]
(001) jeq      #0x800           jt 2	jf 12
(002) ldb      [23]
(003) jeq      #0x6             jt 4	jf 12
(004) ldh      [20]
(005) jset     #0x1fff          jt 12	jf 6
(006) ldxb     4*([14]&0xf)
(007) ldh      [x + 14]
(008) jeq      #0x1f90          jt 11	jf 9
(009) ldh      [x + 16]
(010) jeq      #0x1f90          jt 11	jf 12
(011) ret      #262144
(012) ret      #0

圖 1-1 tcpdump 底層匯編指令

BPF 工作在內核層，BPF 的架構圖如下 [來自于bpf-usenix93]：

圖 1-2 tcpdump 運行架構

2. eBPF

2.1 eBPF 介紹

2014 年初，Alexei Starovoitov 實現了 eBPF（extended Berkeley Packet Filter）。經過重新設計，eBPF 演進為一個通用執行引擎，可基于此開發性能分析工具、軟件定義網絡等諸多場景。eBPF 最早出現在 3.18 內核中，此后原來的 BPF 就被稱為經典 BPF，縮寫 cBPF（classic BPF），cBPF 現在已經基本廢棄。現在，Linux 內核只運行 eBPF，內核會將加載的 cBPF 字節碼透明地轉換成 eBPF 再執行。

eBPF 新的設計針對現代硬件進行了優化，所以 eBPF 生成的指令集比舊的 BPF 解釋器生成的機器碼執行得更快。擴展版本也增加了虛擬機中的寄存器數量，將原有的 2 個 32 位寄存器增加到 10 個 64 位寄存器。由于寄存器數量和寬度的增加，開發人員可以使用函數參數自由交換更多的信息，編寫更復雜的程序。總之，這些改進使 eBPF 版本的速度比原來的 BPF 提高了 4 倍。

表格 1 cBPF 與 eBPF 對比

eBPF 在 Linux 3.18 版本以后引入，并不代表只能在內核 3.18+ 版本上運行，低版本的內核升級到最新也可以使用 eBPF 能力，只是可能部分功能受限，比如我就是在 Linux 發行版本 CentOS Linux release 7.7.1908 內核版本 3.10.0-1062.9.1.el7.x86_64 上運行 eBPF 在生產環境上搜集和排查網絡問題。

eBPF 實現的最初目標是優化處理網絡過濾器的內部 BPF 指令集。當時，BPF 程序仍然限于內核空間使用，只有少數用戶空間程序可以編寫內核處理的 BPF 過濾器，例如：tcpdump和 seccomp。時至今日，這些程序仍基于舊的 BPF 解釋器生成字節碼，但內核中會將這些指令轉換為高性能的內部表示。

2014 年 6 月，eBPF 擴展到用戶空間，這也成為了 BPF 技術的轉折點。 正如 Alexei 在提交補丁的注釋中寫到：“這個補丁展示了 eBPF 的潛力”。當前，eBPF 不再局限于網絡棧，已經成為內核頂級的子系統。eBPF 程序架構強調安全性和穩定性，看上去更像內核模塊，但與內核模塊不同，eBPF 程序不需要重新編譯內核，并且可以確保 eBPF 程序運行完成，而不會造成系統的崩潰。

圖 2-1 BPF 架構圖

簡述概括， eBPF 是一套通用執行引擎，提供了可基于系統或程序事件高效安全執行特定代碼的通用能力，通用能力的使用者不再局限于內核開發者；eBPF 可由執行字節碼指令、存儲對象和 Helper 幫助函數組成，字節碼指令在內核執行前必須通過 BPF 驗證器 Verfier 的驗證，同時在啟用 BPF JIT 模式的內核中，會直接將字節碼指令轉成內核可執行的本地指令運行。

同時，eBPF 也逐漸在觀測（跟蹤、性能調優等）、安全和網絡等領域發揮重要的角色。Facebook、NetFlix 、CloudFlare 等知名互聯網公司內部廣泛采用基于 eBPF 技術的各種程序用于性能分析、排查問題、負載均衡、防范 DDoS 攻擊，據相關信息顯示在 Facebook 的機器上內置一系列 eBPF 的相關工具。

相對于系統的性能分析和觀測，eBPF 技術在網絡技術中的表現，更是讓人眼前一亮，BPF 技術與 XDP（eXpress Data Path） 和 TC（Traffic Control） 組合可以實現功能更加強大的網絡功能，更可為 SDN 軟件定義網絡提供基礎支撐。XDP 只作用與網絡包的 Ingress 層面，BPF 鉤子位于網絡驅動中盡可能早的位置，無需進行原始包的復制就可以實現最佳的數據包處理性能，掛載的 BPF 程序是運行過濾的理想選擇，可用于丟棄惡意或非預期的流量、進行 DDOS 攻擊保護等場景；而 TC Ingress 比 XDP 技術處于更高層次的位置，BPF 程序在 L3 層之前運行，可以訪問到與數據包相關的大部分元數據，是本地節點處理的理想的地方，可以用于流量監控或者 L3/L4 的端點策略控制，同時配合 TC egress 則可實現對于容器環境下更高維度和級別的網絡結構。

圖 2-2 XDP 技術架構

eBPF 相關的知名的開源項目包括但不限于以下：

• Facebook 高性能 4 層負載均衡器?Katran；
• Cilium?為下一代微服務 ServiceMesh 打造了具備API感知和安全高效的容器網絡方案；底層主要使用 XDP 和 TC 等相關技術；
• IO Visor 項目開源的?BCC、?BPFTrace?和?Kubectl-Trace：?BCC?提供了更高階的抽象，可以讓用戶采用 Python、C++ 和 Lua 等高級語言快速開發 BPF 程序；BPFTrace?采用類似于 awk 語言快速編寫 eBPF 程序；Kubectl-Trace?則提供了在 kubernetes 集群中使用 BPF 程序調試的方便操作；
• CloudFlare 公司開源的?eBPF Exporter?和?bpf-tools：eBPF Exporter?將 eBPF 技術與監控 Prometheus 緊密結合起來；bpf-tools?可用于網絡問題分析和排查；

越來越多的基于 eBPF 的項目如雨后脆筍一樣開始蓬勃發展，而且逐步在社區中異軍突起，成為一道風景線。比如 IO Visor 項目的 BCC 工具，為性能分析和觀察提供了更加豐富的工具集：圖片來源

?

?

圖 2-3 Linux bcc/BPF 觀測工具

同時，IO Visor 的?bpf-docs?包含了日常的文檔，可以用于學習。

由于 eBPF 還在快速發展期，內核中的功能也日趨增強，一般推薦基于Linux 4.4+ (4.9 以上會更好) 內核的來使用 eBPF。部分 Linux Event 和 BPF 版本支持見下圖：

圖 2-4 Linux 事件和 BPF 版本支持

2.2 eBPF 架構（觀測）

基于 Linux 系統的觀測工具中，eBPF 有著得天獨厚的優勢，高效、生產安全且內核中內置，特別的可以在內核中完成數據分析聚合比如直方圖，與將數據發送到用戶空間分析聚合相比，能夠節省大量的數據復制傳遞帶來的 CPU 消耗。

eBPF 整體結構圖如下：

圖 2-5 eBPF 觀測架構

eBPF 分為用戶空間程序和內核程序兩部分：

• 用戶空間程序負責加載 BPF 字節碼至內核，如需要也會負責讀取內核回傳的統計信息或者事件詳情；
• 內核中的 BPF 字節碼負責在內核中執行特定事件，如需要也會將執行的結果通過 maps 或者 perf-event 事件發送至用戶空間；

其中用戶空間程序與內核 BPF 字節碼程序可以使用 map 結構實現雙向通信，這為內核中運行的 BPF 字節碼程序提供了更加靈活的控制。

用戶空間程序與內核中的 BPF 字節碼交互的流程主要如下：

1. 我們可以使用 LLVM 或者 GCC 工具將編寫的 BPF 代碼程序編譯成 BPF 字節碼；
2. 然后使用加載程序 Loader 將字節碼加載至內核；內核使用驗證器（verfier） 組件保證執行字節碼的安全性，以避免對內核造成災難，在確認字節碼安全后將其加載對應的內核模塊執行；BPF 觀測技術相關的程序程序類型可能是 kprobes/uprobes/tracepoint/perf_events 中的一個或多個，其中：
   • kprobes：實現內核中動態跟蹤。 kprobes 可以跟蹤到 Linux 內核中的函數入口或返回點，但是不是穩定 ABI 接口，可能會因為內核版本變化導致，導致跟蹤失效。
   • uprobes：用戶級別的動態跟蹤。與 kprobes 類似，只是跟蹤的函數為用戶程序中的函數。
   • tracepoints：內核中靜態跟蹤。tracepoints 是內核開發人員維護的跟蹤點，能夠提供穩定的 ABI 接口，但是由于是研發人員維護，數量和場景可能受限。
   • perf_events：定時采樣和 PMC。
3. 內核中運行的 BPF 字節碼程序可以使用兩種方式將測量數據回傳至用戶空間
   • maps?方式可用于將內核中實現的統計摘要信息（比如測量延遲、堆棧信息）等回傳至用戶空間；
   • perf-event?用于將內核采集的事件實時發送至用戶空間，用戶空間程序實時讀取分析；

如無特殊說明，本文中所說的 BPF 都是泛指 BPF 技術。

2.3 eBPF 的限制

eBPF 技術雖然強大，但是為了保證內核的處理安全和及時響應，內核中的 eBPF 技術也給予了諸多限制，當然隨著技術的發展和演進，限制也在逐步放寬或者提供了對應的解決方案。

• eBPF 程序不能調用任意的內核參數，只限于內核模塊中列出的 BPF Helper 函數，函數支持列表也隨著內核的演進在不斷增加。（todo 添加個數說明）

• eBPF 程序不允許包含無法到達的指令，防止加載無效代碼，延遲程序的終止。

• eBPF 程序中循環次數限制且必須在有限時間內結束，這主要是用來防止在 kprobes 中插入任意的循環，導致鎖住整個系統；解決辦法包括展開循環，并為需要循環的常見用途添加輔助函數。Linux 5.3 在 BPF 中包含了對有界循環的支持，它有一個可驗證的運行時間上限。

• eBPF 堆棧大小被限制在 MAX_BPF_STACK，截止到內核 Linux 5.8 版本，被設置為 512；參見?include/linux/filter.h，這個限制特別是在棧上存儲多個字符串緩沖區時：一個char[256]緩沖區會消耗這個棧的一半。目前沒有計劃增加這個限制，解決方法是改用 bpf 映射存儲，它實際上是無限的。

  /* BPF program can access up to 512 bytes of stack space. */ #define MAX_BPF_STACK 512

• eBPF 字節碼大小最初被限制為 4096 條指令，截止到內核 Linux 5.8 版本， 當前已將放寬至 100 萬指令（ BPF_COMPLEXITY_LIMIT_INSNS），參見：include/linux/bpf.h，對于無權限的BPF程序，仍然保留4096條限制 ( BPF_MAXINSNS )；新版本的 eBPF 也支持了多個 eBPF 程序級聯調用，雖然傳遞信息存在某些限制，但是可以通過組合實現更加強大的功能。

  #define BPF_COMPLEXITY_LIMIT_INSNS 1000000 /* yes. 1M insns */

2.4 eBPF 與內核模塊對比

在 Linux 觀測方面，eBPF 總是會拿來與 kernel 模塊方式進行對比，eBPF 在安全性、入門門檻上比內核模塊都有優勢，這兩點在觀測場景下對于用戶來講尤其重要。

表格 2 eBPF 與 Linux 內核模塊方式對比

3. 應用案例

大名鼎鼎的性能分析大師 Brendan Gregg 等編寫了諸多的 BCC 或 BPFTrace 的工具集可以拿來直接使用，完全可以滿足我們日常問題分析和排查。

BCC 在 CentOS 7 系統中可以通過 yum 快速安裝

# yum install bcc -y
Resolving Dependencies
--> Running transaction check
---> Package bcc.x86_64 0:0.8.0-1.el7 will be updated
--> Processing Dependency: bcc(x86-64) = 0.8.0-1.el7 for package: python-bcc-0.8.0-1.el7.x86_64
---> Package bcc.x86_64 0:0.10.0-1.el7 will be an update
--> Processing Dependency: bcc-tools = 0.10.0-1.el7 for package: bcc-0.10.0-1.el7.x86_64
--> Running transaction check
---> Package bcc-tools.x86_64 0:0.8.0-1.el7 will be updated
---> Package bcc-tools.x86_64 0:0.10.0-1.el7 will be an update
---> Package python-bcc.x86_64 0:0.8.0-1.el7 will be updated
---> Package python-bcc.x86_64 0:0.10.0-1.el7 will be an update
--> Finished Dependency Resolution
...

其他系統的安裝方式參見：INSTALL.md

BCC 中每一個工具都有一個對應的使用樣例，比如?execsnoop.py?和?execsnoop_example.txt，在使用樣例中有詳細的使用說明，而且 BCC 中的工具使用的幫助文檔格式基本類似，上手非常方便。

BCC 的程序一般情況下都需要 root 用戶來運行。

3.1 Linux 性能分析 60 秒 （BPF版本）

英文原文?Linux Performance Analysis in 60,000 Milliseconds，視頻地址

uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top

60s 系列 BPF 版本如下：

圖 3-1 60s 排查之 BPF 版本

對于在系統中運行的 “閃電俠” 程序，運行周期非常短，但是可能會帶來系統的抖動延時，我們采用?top?命令查看一般情況下難以發現，我們可以使用 BCC 提供的工具?execsnoop?來進行排查：

# Trace file opens with process and filename: opensnoop
#/usr/share/bcc/tools/execsnoop 
PCOMM            PID    PPID   RET ARGS
sleep            3334   21029    0 /usr/bin/sleep 3
sleep            3339   21029    0 /usr/bin/sleep 3
conntrack        3341   1112     0 /usr/sbin/conntrack --stats
conntrack        3342   1112     0 /usr/sbin/conntrack --count
sleep            3344   21029    0 /usr/bin/sleep 3
iptables-save    3347   9211     0 /sbin/iptables-save -t filter
iptables-save    3348   9211     0 /sbin/iptables-save -t nat

3.2?slab dentry 過大導致的網絡抖動排查

現象

網絡 ping 的延時間歇性有規律出現抖動

問題排查

采用?execsnoop?分析發現，某個運行命令cat /proc/slabinfo的運行時間間隔與抖動的頻率完全吻合，順著這個的線索定位，我們發現云廠商提供的 Java 版本的云監控會定期調用?cat /proc/slabinfo?來獲取內核緩存的信息；

通過命令?slabtop?發現系統中的?dentry?項的內存占用非常大，系統內存 128G，dentry?占用 70G 以上，所以問題很快就定位到是系統在打開文件方面可能有相關問題；

根因分析

我們使用對于打開文件跟蹤的 BCC 工具?opensnoop?很快就定位到是某個程序頻繁創建和刪除臨時文件，最終定位為某個 PHP 程序設置的調用方式存在問題，導致每次請求會創建和刪除臨時文件；代碼中將 http 調用中的?contentType?設置成了?Http::CONTENT_TYPE_UPLOAD，導致每次請求都會生成臨時文件，修改成?application/x-www-form-urlencoded?問題解決。

問題的原理可參考?記一次對網絡抖動經典案例的分析?和?systemtap腳本分析系統中dentry SLAB占用過高問題

3.3 生成火焰圖

火焰圖是幫助我們對系統耗時進行可視化的圖表，能夠對程序中那些代碼經常被執行給出一個清晰的展現。Brendan Gregg 是火焰圖的創建者，他在?GitHub?上維護了一組腳本可以輕松生成需要的可視化格式數據。使用 BCC 中的工具?profile?可很方面地收集道 CPU 路徑的數據，基于數據采用工具可以輕松地生成火焰圖，查找到程序的性能瓶頸。

使用?profile?搜集火焰圖的程序沒有任何限制和改造

profile?工具可以讓我們輕松對于系統或者程序的 CPU 性能路徑進行可視化分析：

/usr/share/bcc/tools/profile -h
usage: profile [-h] [-p PID | -L TID] [-U | -K] [-F FREQUENCY | -c COUNT] [-d][-a] [-I] [-f] [--stack-storage-size STACK_STORAGE_SIZE][-C CPU][duration]Profile CPU stack traces at a timed intervalpositional arguments:duration              duration of trace, in secondsoptional arguments:-h, --help            show this help message and exit-p PID, --pid PID     profile process with this PID only-L TID, --tid TID     profile thread with this TID only-U, --user-stacks-onlyshow stacks from user space only (no kernel spacestacks)-K, --kernel-stacks-onlyshow stacks from kernel space only (no user spacestacks)-F FREQUENCY, --frequency FREQUENCYsample frequency, Hertz-c COUNT, --count COUNTsample period, number of events-d, --delimited       insert delimiter between kernel/user stacks-a, --annotations     add _[k] annotations to kernel frames-I, --include-idle    include CPU idle stacks-f, --folded          output folded format, one line per stack (for flamegraphs)--stack-storage-size STACK_STORAGE_SIZEthe number of unique stack traces that can be storedand displayed (default 16384)-C CPU, --cpu CPU     cpu number to run profile onexamples:./profile             # profile stack traces at 49 Hertz until Ctrl-C./profile -F 99       # profile stack traces at 99 Hertz./profile -c 1000000  # profile stack traces every 1 in a million events./profile 5           # profile at 49 Hertz for 5 seconds only./profile -f 5        # output in folded format for flame graphs./profile -p 185      # only profile process with PID 185./profile -L 185      # only profile thread with TID 185./profile -U          # only show user space stacks (no kernel)./profile -K          # only show kernel space stacks (no user)

profile?配合?FlameGraph?可以輕松幫我們繪制出 CPU 使用的火焰圖。

$ profile -af 30 > out.stacks01
$ git clone https://github.com/brendangregg/FlameGraph
$ cd FlameGraph
$ ./flamegraph.pl --color=java < ../out.stacks01 > out.svg

圖 3-2 火焰圖

3.3 排查網絡調用來源

在生產場景下，會有些特定場景需要抓取連接到外網特定地址的程序，這時候我們可以采用 BCC 工具集中的?tcplife?來定位。

/usr/share/bcc/tools/tcplife -h
usage: tcplife [-h] [-T] [-t] [-w] [-s] [-p PID] [-L LOCALPORT][-D REMOTEPORT]Trace the lifespan of TCP sessions and summarizeoptional arguments:-h, --help            show this help message and exit-T, --time            include time column on output (HH:MM:SS)-t, --timestamp       include timestamp on output (seconds)-w, --wide            wide column output (fits IPv6 addresses)-s, --csv             comma separated values output-p PID, --pid PID     trace this PID only-L LOCALPORT, --localport LOCALPORTcomma-separated list of local ports to trace.-D REMOTEPORT, --remoteport REMOTEPORTcomma-separated list of remote ports to trace.examples:./tcplife           # trace all TCP connect()s./tcplife -t        # include time column (HH:MM:SS)./tcplife -w        # wider colums (fit IPv6)./tcplife -stT      # csv output, with times & timestamps./tcplife -p 181    # only trace PID 181./tcplife -L 80     # only trace local port 80./tcplife -L 80,81  # only trace local ports 80 and 81./tcplife -D 80     # only trace remote port 80

通過在機器上使用?tcplife?來獲取的網絡連接信息，我們可以看到包括了 PID、COMM、本地 IP 地址、本地端口、遠程 IP 地址和遠程端口，通過這些信息非常方便排查到連接到特定 IP 地址的程序，尤其是連接的過程非常短暫，通過?netstat?等其他工具不容易排查的場景。

# /usr/share/bcc/tools/tcplife
PID   COMM             IP LADDR                      LPORT RADDR                  RPORT  TX_KB  RX_KB MS
1776  blackbox_export  4  169.254.20.10              35830 169.254.20.10          53       0      0 0.36
27150 node-cache       4  169.254.20.10              53    169.254.20.10          35830    0      0 0.36
12511 coredns          4  127.0.0.1                  58492 127.0.0.1              8080     0      0 0.32
...

如果我們想知道更加詳細的 TCP 狀態情況，那么?tcptracer?可展示更加詳細的 TCP 狀態，其中 C 代表 Connect X 表示關閉， A 代表 Accept。

# /usr/share/bcc/tools/tcptracer 
Tracing TCP established connections. Ctrl-C to end.
T  PID    COMM             IP SADDR            DADDR            SPORT  DPORT
C  21066  ilogtail         4  10.81.128.12     100.100.49.128   40906  80
X  21066  ilogtail         4  10.81.128.12     100.100.49.128   40906  80
C  21066  ilogtail         4  10.81.128.12     100.100.49.128   40908  80
X  21066  ilogtail         4  10.81.128.12     100.100.49.128   40908  80

tcpstates?還能夠展示出來 TCP 狀態機的流轉情況：

# /usr/share/bcc/tools/tcpstates
SKADDR           C-PID C-COMM     LADDR           LPORT RADDR           RPORT OLDSTATE    -> NEWSTATE    MS
ffff9fd7e8192000 22384 curl       100.66.100.185  0     52.33.159.26    80    CLOSE       -> SYN_SENT    0.000
ffff9fd7e8192000 0     swapper/5  100.66.100.185  63446 52.33.159.26    80    SYN_SENT    -> ESTABLISHED 1.373
ffff9fd7e8192000 22384 curl       100.66.100.185  63446 52.33.159.26    80    ESTABLISHED -> FIN_WAIT1   176.042

同樣，我們也可以實時獲取到 TCP 連接超時或者重連的網絡連接；也可以通過抓取 UDP包相關的連接信息，用于定位諸如 DNS 請求超時或者 DNS 請求的發起進程。

4. 編寫 BPF 程序

對于大多數開發者而言，更多的是基于 BPF 技術之上編寫解決我們日常遇到的各種問題，當前 BCC 和 BPFTrace 兩個項目在觀測和性能分析上已經有了諸多靈活且功能強大的工具箱，完全可以滿足我們日常使用。

• BCC?提供了更高階的抽象，可以讓用戶采用 Python、C++ 和 Lua 等高級語言快速開發 BPF 程序；
• BPFTrace?采用類似于 awk 語言快速編寫 eBPF 程序；

更早期的工具則是使用 C 語言來編寫 BPF 程序，使用 LLVM clang 編譯成 BPF 代碼，這對于普通使用者上手有不少門檻當前僅限于對于 eBPF 技術更加深入的學習場景。

4.1 BCC 版本 HelloWorld

圖 4-1 BCC 整體架構

使用 BCC 前端綁定語言 Python 編寫的 Hello World 版本：

#!/usr/bin/python3from bcc import BPF# This may not work for 4.17 on x64, you need replace kprobe__sys_clone with kprobe____x64_sys_clone
prog = """int kprobe__sys_clone(void *ctx) {bpf_trace_printk("Hello, World!\\n");return 0;}
"""b = BPF(text=prog, debug=0x04)
b.trace_print()

運行程序前需要安裝過 bcc 相關工具包，當運行正常的時候我們發現每當?sys_clone?系統調用時，運行的控制臺上就會打印 “Hello, World!”，在打印文字前面還包含了調用程序的進程名稱，進程 ID 等信息；

如果運行報錯，可能是缺少頭文件，一般安裝 kernel-devel 包即可。

# python ./hello.pykubelet-8349  [006] d... 33637334.829981: : Hello, World!kubelet-8349  [006] d... 33637334.838594: : Hello, World!kubelet-8349  [006] d... 33637334.843788: : Hello, World!

4.3 BPFTrace

BPFTrace 是基于 BPF 和 BCC 的開源項目，與 BCC 不同的是其提供了更高層次的抽象，可以使用類似 AWK 腳本語言來編寫基于 BPF 的跟蹤或者性能排查工具，更加易于入門和編寫，該工具的主要靈感來自于 Solaris 的 D 語言。BPFTrace 更方便與編寫單行的程序。BPFTrace 與 BCC 一樣也是 IO Visor 組織下的項目，倉庫參見?bpftrace。更加深入的學習資料參見：Reference Guide?和?One-Liner Tutorial。

BPFTrace 使用 LLVM 將腳本編譯成 BPF 二進制碼，后續使用 BCC 與 Linux 內核進行交互。從功能層面上講，BPFTrace 的定制性和靈活性不如 BCC，但是比 BCC 工具更加易于理解和使用，降低了 BPF 技術的使用門檻。

使用樣例：

# 統計進程調用 sys_enter 的次數
#bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'
Attaching 1 probe...
^C@[bpftrace]: 6
@[systemd]: 24
@[snmp-pass]: 96
@[sshd]: 125# 統計內核中函數堆棧的次數
# bpftrace -e 'profile:hz:99 { @[kstack] = count(); }'
Attaching 1 probe...
^C[...]
@[
filemap_map_pages+181
__handle_mm_fault+2905
handle_mm_fault+250
__do_page_fault+599
async_page_fault+69
]: 12
[...]
@[
cpuidle_enter_state+164
do_idle+390
cpu_startup_entry+111
start_secondary+423
secondary_startup_64+165
]: 22122

4.3 C 語言原生方式

采用 LLVM Clang 的方式編譯會涉及到內核編譯環境搭建，而且還需要自己編譯 Makefile 等操作，屬于高級用戶使用：

bpf_program.c

#include <linux/bpf.h>
#define SEC(NAME) __attribute__((section(NAME), used))static int (*bpf_trace_printk)(const char *fmt, int fmt_size,...) = (void *)BPF_FUNC_trace_printk;SEC("tracepoint/syscalls/sys_enter_execve")
int bpf_prog(void *ctx) {char msg[] = "Hello, BPF World!";bpf_trace_printk(msg, sizeof(msg));return 0;
}char _license[] SEC("license") = "GPL";

loader.c

#include "bpf_load.h"
#include <stdio.h>int main(int argc, char **argv) {if (load_bpf_file("bpf_program.o") != 0) {printf("The kernel didn't load the BPF program\n");return -1;}read_trace_pipe();return 0;
}

Makefile 文件（部分）

build: ${BPFCODE.c} ${BPFLOADER}$(CLANG) -O2 -target bpf -c $(BPFCODE:=.c) $(CCINCLUDE) -o ${BPFCODE:=.o}

其中 clang 編譯中的選型?-target bpf?表明我們將代碼編譯成 bpf 的字節碼。

完整的程序參見：hello_world；更多的樣例代碼可以參見對應內核中?kernel-src/samples/bpf/?下的樣例代碼。

5. 國內大廠 eBPF 實踐經驗

• eBPF 在網易輕舟云原生的應用實踐

• 性能提升40%: 騰訊 TKE 用 eBPF繞過 conntrack 優化K8s Service

• 字節跳動：eBPF 技術實踐：高性能 ACL

• 阿里：eBPF Internal：Instructions and Runtime

• 使用 ebpf 深入分析容器網絡 dup 包問題

• eBay 云計算“網”事：網絡超時篇?eBay云計算“網”事｜網絡丟包篇

• 字節跳動容器化場景下的性能優化實踐

6. 參考資料

1. The BSD Packet Filter: A New Architecture for User-level Packet Capture

2. [譯] Cilium：BPF 和 XDP 參考指南（2019）?Cillum BPF and XDP Reference Guide

3. Cloudflare架構以及BPF如何占據世界

4. 關於 BPF 和 eBPF 的筆記

5. Dive into BPF: a list of reading material?中文

6. eBPF 簡史

7. https://www.youtube.com/watch?v=znBGt7oHJyQ

8. BPF Documentation?HOWTO interact with BPF subsystem

9. Linux 內核 BPF 文檔

10. Linux Extended BPF (eBPF) Tracing Tools?Brendan Gregg

11. 性能提升40%: 騰訊 TKE 用 eBPF繞過 conntrack 優化K8s Service

12. SDN handbook

13. Linux BPF 幫助文檔?bpf(2)?bpf-helpers(7)?tc-bpf(8)

    1. user commands

    2. system calls

    3. library functions

    4. special files

    5. file formats and filesystems

    6. games

    7. overview and miscellany section

    8. administration and privileged commands

    參考：https://man7.org/linux/man-pages/index.html

• 原文作者：DavidDi
• 原文鏈接：https://www.ebpf.top/post/ebpf_intro/
• 版權聲明：本作品采用知識共享署名-非商業性使用-禁止演繹 4.0 國際許可協議進行許可，非商業轉載請注明出處（作者，原文鏈接），商業轉載請聯系作者獲得授權。

總結

以上是生活随笔為你收集整理的【BPF入门系列-1】eBPF 技术简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。