910      技術社區[雲棲]

Linux 中的 DTrace ：BPF 進入 4.9 內核

隨著 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 目錄下添加一係列工具，包括接下來的那些工具。

捕獲新進程：

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

硬盤 I/O 延遲的柱狀圖：

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

追蹤慢於 5 毫秒的 ext4 常見操作：

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

追蹤新建的 TCP 活躍連接（connect()）:

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

通過跟蹤 getaddrinfo()/gethostbyname() 庫的調用來追蹤 DNS 延遲：

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

按類別劃分 VFS 操作的時間間隔統計：

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

對一個給定的 PID，通過內核和用戶堆棧軌跡來追蹤 CPU 處理之外的時間（由內核進行統計）：

1. # offcputime -d -p 24347
2. Tracing off-CPU time (us) of PID 24347 by user + kernel stack... Hit Ctrl-C to end.
3. ^C
4. [...]
5. ffffffff810a9581 finish_task_switch
6. ffffffff8185d385 schedule
7. ffffffff81085672 do_wait
8. ffffffff8108687b sys_wait4
9. ffffffff81861bf6 entry_SYSCALL_64_fastpath
10. --
11. 00007f6733a6b64a waitpid
12. - bash (24347)
13. 4952
15. ffffffff810a9581 finish_task_switch
16. ffffffff8185d385 schedule
17. ffffffff81860c48 schedule_timeout
18. ffffffff810c5672 wait_woken
19. ffffffff8150715a n_tty_read
20. ffffffff815010f2 tty_read
21. ffffffff8122cd67 __vfs_read
22. ffffffff8122df65 vfs_read
23. ffffffff8122f465 sys_read
24. ffffffff81861bf6 entry_SYSCALL_64_fastpath
25. --
26. 00007f6733a969b0 read
27. - bash (24347)
28. 1450908

追蹤 MySQL 查詢延遲（通過 USDT 探針）：

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

監測 pam 庫並使用多種追蹤工具觀察登錄請求：

1. # trace 'pam:pam_start "%s: %s", arg1, arg2'
2. TIME PID COMM FUNC -
3. 17:49:45 5558 sshd pam_start sshd: root
4. 17:49:47 5662 sudo pam_start sudo: root
5. 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 大小的柱狀圖代碼：

1. from bcc import BPF
2. from time import sleep
4. # load BPF program
5. b = BPF(text="""
6. #include <uapi/linux/ptrace.h>
7. #include <linux/blkdev.h>
9. BPF_HISTOGRAM(dist);
11. int kprobe__blk_account_io_completion(struct pt_regs *ctx, struct request *req)
12. {
13. dist.increment(bpf_log2l(req->__data_len / 1024));
14. return 0;
15. }
16. """)
18. # header
19. print("Tracing... Hit Ctrl-C to end.")
21. # trace until Ctrl-C
22. try:
23. sleep(99999999)
24. except KeyboardInterrupt:
25. print
27. # output
28. b["dist"].print_log2_hist("kbytes")

注意 Python 代碼中嵌入的 C 語句（text=）。

這就完成了任務，但仍有改進的空間。好在我們有時間去做：人們使用 Linux 4.9 並能用上 BPF 還得好幾個月呢，所以我們有時間來製造工具和前端。

高級語言

前端越簡單，比如高級語言，所改進的可能就越不如你所期望的。絕大多數人使用封裝好的工具（和圖形界麵），僅有少部分人能寫出這些工具。但我不反對使用高級語言，比如 SystemTap，畢竟已經開發出來了。

1. #!/usr/bin/stap
2. /*
3. * opensnoop.stp Trace file open()s. Basic version of opensnoop.
4. */
6. probe begin
7. {
8. printf("\n%6s %6s %16s %s\n", "UID", "PID", "COMM", "PATH");
9. }
11. probe syscall.open
12. {
13. printf("%6d %6d %16s %s\n", uid(), pid(), execname(), filename);
14. }

如果擁有整合了語言和腳本的 SystemTap 前端與高性能的內置在內核中的 BPF 後端，會不會令人滿意呢？RedHat 公司的 Richard Henderson 已經在進行相關工作了，並且發布了 初代版本！

這是 ply，一個完全新穎的 BPF 高級語言：

1. #!/usr/bin/env ply
3. kprobe:SyS_*
4. {
5. $syscalls[func].count()
6. }

這也是一份承諾。

盡管如此，我認為工具開發者的實際難題不是使用什麼語言：而是要了解要用這些強大的工具做什麼？

如何幫助我們

• 推廣：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 中使用它。

原文發布時間為：2017-12-19

本文來自雲棲社區合作夥伴“Linux中國”

最後更新：2017-06-06 07:37:26

  上一篇：  用數據科學搭建一個實時推薦引擎

  下一篇：  httpstat：一個檢查網站性能的 curl 統計分析工具