Linux中的DTrace：BPF進(jìn)入4.9內(nèi)核
隨著 BPF 追蹤系統(tǒng)(基于時(shí)間采樣)***一個(gè)主要功能被合并至 Linux 4.9-rc1 版本的內(nèi)核中，現(xiàn)在 Linux 內(nèi)核擁有類似 DTrace 的原生追蹤功能。DTrace 是 Solaris 系統(tǒng)中的高級(jí)追蹤器。對(duì)于長(zhǎng)期使用 DTrace 的用戶和專家，這將是一個(gè)振奮人心的里程碑!現(xiàn)在在 Linux 系統(tǒng)上，你可以在生產(chǎn)環(huán)境中使用安全的、低負(fù)載的定制追蹤系統(tǒng)，通過執(zhí)行時(shí)間的柱狀圖和頻率統(tǒng)計(jì)等信息，分析應(yīng)用的性能以及內(nèi)核。
用于 Linux 的追蹤項(xiàng)目有很多，但是這個(gè)最終被合并進(jìn) Linux 內(nèi)核的技術(shù)從一開始就根本不是一個(gè)追蹤項(xiàng)目：它是最開始是用于伯克利***濾器Berkeley Packet Filter(BPF)的增強(qiáng)功能。這些補(bǔ)丁允許 BPF 重定向數(shù)據(jù)包，從而創(chuàng)建軟件定義網(wǎng)絡(luò)(SDN)。久而久之，對(duì)事件追蹤的支持就被添加進(jìn)來了，使得程序追蹤可用于 Linux 系統(tǒng)。
盡管目前 BPF 沒有像 DTrace 一樣的高級(jí)語言，但它所提供的前端已經(jīng)足夠讓我創(chuàng)建很多 BPF 工具了，其中有些是基于我以前的 DTraceToolkit。這個(gè)帖子將告訴你怎么去用這些 BPF 提供的前端工具，以及暢談這項(xiàng)技術(shù)將會(huì)何去何從。
示例
我已經(jīng)將基于 BPF 的追蹤工具添加到了開源的 bcc 項(xiàng)目里(感謝 PLUMgrid 公司的 Brenden Blanco 帶領(lǐng) bcc 項(xiàng)目的發(fā)展)。詳見 bcc 安裝 手冊(cè)。它會(huì)在 /usr/share/bcc/tools 目錄下添加一系列工具，包括接下來的那些工具。
捕獲新進(jìn)程：
- # 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() 庫(kù)的調(diào)用來追蹤 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 操作的時(shí)間間隔統(tǒng)計(jì)：
- # 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
對(duì)一個(gè)給定的 PID，通過內(nèi)核和用戶堆棧軌跡來追蹤 CPU 處理之外的時(shí)間(由內(nèi)核進(jìn)行統(tǒng)計(jì))：
- # 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
監(jiān)測(cè) pam 庫(kù)并使用多種追蹤工具觀察登錄請(qǐng)求：
- # 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 項(xiàng)目里的很多工具都有幫助信息(-h 選項(xiàng))，并且都應(yīng)該包含有示例的 man 頁面和文本文件。
必要性
2014 年，Linux 追蹤程序就有一些內(nèi)核相關(guān)的特性(來自 ftrace 和 pref_events)，但是我們?nèi)匀灰D(zhuǎn)儲(chǔ)并報(bào)告進(jìn)程數(shù)據(jù)，這種幾十年前的老技術(shù)有很多的限制。你不能頻繁地訪問進(jìn)程名、函數(shù)名、堆棧軌跡或內(nèi)核中的任意的其它數(shù)據(jù)。你不能在將變量保存到一個(gè)監(jiān)測(cè)事件里，又在另一個(gè)事件里訪問它們，這意味著你不能在你需要的地方計(jì)算延遲(或者說時(shí)間增量)。你也不能創(chuàng)建一個(gè)內(nèi)核內(nèi)部的延遲柱狀圖，也不能追蹤 USDT 探針，甚至不能寫個(gè)自定義的程序。DTrace 可以做到所有這些，但僅限于 Solaris 或 BSD 系統(tǒng)。在 Linux 系統(tǒng)中，有些不在主線內(nèi)核的追蹤器，比如 SystemTap 就可以滿足你的這些需求，但它也有自身的不足。(理論上說，你可以寫一個(gè)基于探針的內(nèi)核模塊來滿足需求-但實(shí)際上沒人這么做。)
2014 年我加入了 Netflix cloud performance 團(tuán)隊(duì)。做了這么久的 DTrace 方面的專家，轉(zhuǎn)到 Linux 對(duì)我來說簡(jiǎn)直不可思議。但我確實(shí)這么做了，而且遇到了巨大的挑戰(zhàn)：在應(yīng)用快速變化、采用微服務(wù)架構(gòu)和分布式系統(tǒng)的情況下，調(diào)優(yōu) Netflix cloud。有時(shí)要用到系統(tǒng)追蹤，而我之前是用的 DTrace。在 Linux 系統(tǒng)上可沒有 DTrace，我就開始用 Linux 內(nèi)核內(nèi)建的 ftrace 和 perf_events 工具，構(gòu)建了一個(gè)追蹤工具(perf-tools)。這些工具很有用，但有些工作還是沒法完成，尤其是延遲柱狀圖以及堆棧蹤跡計(jì)數(shù)。我們需要的是內(nèi)核追蹤的可程序化。
發(fā)生了什么?
BPF 將程序化的功能添加到現(xiàn)有的內(nèi)核追蹤工具中(tracepoints、kprobes、uprobes)。在 Linux 4.x 系列的內(nèi)核里，這些功能大大加強(qiáng)了。
時(shí)間采樣是最主要的部分，它被 Linux 4.9-rc1 所采用(patchset)。十分感謝 Alexei Starovoitov(在 Facebook 致力于 BPF 的開發(fā))，他是這些 BPF 增強(qiáng)功能的主要開發(fā)者。
Linux 內(nèi)核現(xiàn)在內(nèi)建有以下這些特性(自 2.6 版本到 4.9 版本之間增加)：
- 內(nèi)核級(jí)的動(dòng)態(tài)追蹤(BPF 對(duì) kprobes 的支持)
- 用戶級(jí)的動(dòng)態(tài)追蹤(BPF 對(duì) uprobes 的支持)
- 內(nèi)核級(jí)的靜態(tài)追蹤(BPF 對(duì) tracepoints 的支持)
- 時(shí)間采樣事件(BPF 的 pref_event_open)
- PMC 事件(BPF 的 pref_event_open)
- 過濾器(通過 BPF 程序)
- 調(diào)試輸出(bpf_trace_printk())
- 按事件輸出(bpf_perf_event_output())
- 基礎(chǔ)變量(全局的和每個(gè)線程的變量，基于 BPF 映射)
- 關(guān)聯(lián)數(shù)組(通過 BPF 映射)
- 頻率計(jì)數(shù)(基于 BPF 映射)
- 柱狀圖(2 的冥次方、線性及自定義，基于 BPF 映射)
- 時(shí)間戳和時(shí)間增量(bpf_ktime_get_ns()，和 BPF 程序)
- 內(nèi)核態(tài)的堆棧軌跡(BPF 棧映射)
- 用戶態(tài)的堆棧軌跡 (BPF 棧映射)
- 重寫 ring 緩存(pref_event_attr.write_backward)
我們采用的前端是 bcc，它同時(shí)提供 Python 和 lua 接口。bcc 添加了：
- 用戶級(jí)靜態(tài)追蹤(基于 uprobes 的 USDT 探針)
- 調(diào)試輸出(Python 中調(diào)用 BPF.trace_pipe() 和 BPF.trace_fields() 函數(shù) )
- 按事件輸出(BPF_PERF_OUTPUT 宏和 BPF.open_perf_buffer())
- 間隔輸出(BPF.get_table() 和 table.clear())
- 打印柱狀圖(table.print_log2_hist())
- 內(nèi)核級(jí)的 C 結(jié)構(gòu)體導(dǎo)航(bcc 重寫器映射到 bpf_probe_read() 函數(shù))
- 內(nèi)核級(jí)的符號(hào)解析(ksym()、 ksymaddr())
- 用戶級(jí)的符號(hào)解析(usymaddr())
- BPF 跟蹤點(diǎn)支持(通過 TRACEPOINT_PROBE)
- BPF 堆棧軌跡支持(包括針對(duì)堆?？蚣艿?walk 方法)
- 其它各種輔助宏和方法
- 例子(位于 /examples 目錄)
- 工具(位于 /tools 目錄)
- 教程(/docs/tutorial*.md)
- 參考手冊(cè)(/docs/reference_guide.md)
直到***也是最主要的特性被整合進(jìn)來，我才開始寫這篇文章，現(xiàn)在它在 4.9-rc1 內(nèi)核中。我們還需要去完成一些次要的東西，還有另外一些事情要做，但是現(xiàn)在我們所擁有的已經(jīng)值得歡呼了?，F(xiàn)在 Linux 擁有了內(nèi)建的高級(jí)追蹤能力。
安全性
設(shè)計(jì) BPF 及其增強(qiáng)功能時(shí)就考慮到生產(chǎn)環(huán)境級(jí)安全，它被用在大范圍的生產(chǎn)環(huán)境里。不過你想的話，你還是可以找到一個(gè)掛起內(nèi)核的方法。這種情況是偶然的，而不是必然，類似的漏洞會(huì)被快速修復(fù)，尤其是當(dāng) BPF 合并入了 Linux。因?yàn)?Linux 可是公眾的焦點(diǎn)。
在開發(fā)過程中我們碰到了一些非 BPF 的漏洞，它們需要被修復(fù)：rcu 不可重入，這可能導(dǎo)致內(nèi)核由于 funccount 掛起，在 4.6 內(nèi)核版本中這個(gè)漏洞被 “bpf: map pre-alloc” 補(bǔ)丁集所修復(fù)，舊版本內(nèi)核的漏洞 bcc 有個(gè)臨時(shí)處理方案。還有一個(gè)是 uprobe 的內(nèi)存計(jì)算問題，這導(dǎo)致 uprobe 分配內(nèi)存失敗，在 4.8 內(nèi)核版本這個(gè)漏洞由 “uprobes: Fix the memcg accounting” 補(bǔ)丁所修復(fù)，并且該補(bǔ)丁還將被移植到之前版本的內(nèi)核中(例如，它現(xiàn)在被移植到了 4.4.27 和 4.4.0-45.66 版本中)。
為什么 Linux 追蹤用了這么久才加進(jìn)來?
首要任務(wù)被分到了若干追蹤器中間：這些不是某個(gè)追蹤器單個(gè)的事情。想要了解更多關(guān)于這個(gè)或其它方面的問題，可以看一看我在 2014 年 tracing summit 上的講話。我忽視了部分方案的反面影響：有些公司發(fā)現(xiàn)其它追蹤器(SystemTap 和 LTTng)能滿足他們的需求，盡管他們樂于聽到 BPF 的開發(fā)進(jìn)程，但考慮到他們現(xiàn)有的解決方案，幫助 BPF 的開發(fā)就不那么重要了。
BPF 僅在近兩年里在追蹤領(lǐng)域得到加強(qiáng)。這一過程原本可以更快的，但早期缺少全職從事于 BPF 追蹤的工程師。Alexei Starovoitov (BPF ***)，Brenden Blanco (bcc ***)，我還有其它一些開發(fā)者，都有其它的事情要做。我在 Netflix 公司花了大量時(shí)間(志愿地)，大概有 7% 的時(shí)間是花在 BPF 和 bcc 上。某種程度上這不是我的首要任務(wù)，因?yàn)槲疫€有自己的工作(包括我的 perf-tools，一個(gè)可以工作在舊版本內(nèi)核上的程序)。
現(xiàn)在BPF 追蹤器已經(jīng)推出了，已經(jīng)有科技公司開始尋找會(huì) BPF 的人了。但我還是推薦 Netflix 公司。(如果你為了 BPF 而要聘請(qǐng)我，那我還是十分樂于待在 Netflix 公司的!)
使用簡(jiǎn)單
DTrace 和 bcc/BPF 現(xiàn)在的***區(qū)別就是哪個(gè)更好使用。這取決于你要用 BPF 追蹤做什么了。如果你要
- 使用 BPF 工具/度量：應(yīng)該是沒什么區(qū)別的。工具的表現(xiàn)都差不多，圖形用戶界面都能取得類似度量指標(biāo)。大部分用戶通過這種方式使用 BPF。
- 開發(fā)工具/度量：bcc 的開發(fā)可難多了。DTrace 有一套自己的簡(jiǎn)單語言，D 語音，和 awk 語言相似，而 bcc 使用已有的語言(C 語言，Python 和 lua)及其類庫(kù)。一個(gè)用 C 和 Python 寫的 bcc 工具與僅僅用 D 語言寫出來的工具相比，可能要多十多倍行數(shù)的代碼，或者更多。但是很多 DTrace 工具用 shell 封裝來提供參數(shù)和差錯(cuò)檢查，會(huì)讓代碼變得十分臃腫。編程的難處是不同的：重寫 bcc 更需要巧妙性，這導(dǎo)致某些腳本更加難開發(fā)。(尤其是 bpf_probe_read() 這類的函數(shù)，需要了解更多 BPF 的內(nèi)涵知識(shí))。當(dāng)計(jì)劃改進(jìn) bcc 時(shí)，這一情形將得到改善。
- 運(yùn)行常見的命令：十分相近。通過 dtrace 命令，DTrace 能做很多事，但 bcc 有各種工具，trace、argdist、funccount、funclatency 等等。
- 編寫自定義的特殊命令：使用 DTrace 的話，這就沒有必要了。允許定制消息快速傳遞和系統(tǒng)快速響應(yīng)，DTrace 的高級(jí)分析很快。而 bcc 現(xiàn)在受限于它的多種工具以及它們的適用范圍。
簡(jiǎn)單來說，如果你只使用 BPF 工具的話，就不必關(guān)注這些差異了。如果你經(jīng)驗(yàn)豐富，是個(gè)開發(fā)者(像我一樣)，目前 bcc 的使用更難一些。
舉一個(gè) 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:
- # output
- b["dist"].print_log2_hist("kbytes")
注意 Python 代碼中嵌入的 C 語句(text=)。
這就完成了任務(wù)，但仍有改進(jìn)的空間。好在我們有時(shí)間去做：人們使用 Linux 4.9 并能用上 BPF 還得好幾個(gè)月呢，所以我們有時(shí)間來制造工具和前端。
高級(jí)語言
前端越簡(jiǎn)單，比如高級(jí)語言，所改進(jìn)的可能就越不如你所期望的。絕大多數(shù)人使用封裝好的工具(和圖形界面)，僅有少部分人能寫出這些工具。但我不反對(duì)使用高級(jí)語言，比如 SystemTap，畢竟已經(jīng)開發(fā)出來了。
- #!/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 前端與高性能的內(nèi)置在內(nèi)核中的 BPF 后端，會(huì)不會(huì)令人滿意呢?RedHat 公司的 Richard Henderson 已經(jīng)在進(jìn)行相關(guān)工作了，并且發(fā)布了 初代版本!
這是 ply，一個(gè)完全新穎的 BPF 高級(jí)語言：
- #!/usr/bin/env ply
- kprobe:SyS_*
- {
- $syscalls[func].count()
- }
這也是一份承諾。
盡管如此，我認(rèn)為工具開發(fā)者的實(shí)際難題不是使用什么語言：而是要了解要用這些強(qiáng)大的工具做什么?
如何幫助我們
- 推廣：BPF 追蹤器目前還沒有什么市場(chǎng)方面的進(jìn)展。盡管有公司了解并在使用它(Facebook、Netflix、Github 和其它公司)，但要廣為人知尚需時(shí)日。你可以分享關(guān)于 BPF 的文章和資源給業(yè)內(nèi)的其它公司來幫助我們。
- 教育：你可以撰寫文章，發(fā)表演講，甚至參與 bcc 文檔的編寫。分享 BPF 如何解決實(shí)際問題以及為公司帶來收益的實(shí)例。
- 解決 bcc 的問題：參考 bcc issue list，這包含了錯(cuò)誤和需要的特性。
- 提交錯(cuò)誤：使用 bcc/BPF，提交你發(fā)現(xiàn)的錯(cuò)誤。
- 創(chuàng)造工具：有很多可視化的工具需要開發(fā)，但請(qǐng)不要太草率，因?yàn)榇蠹視?huì)先花幾個(gè)小時(shí)學(xué)習(xí)使用你做的工具，所以請(qǐng)盡量把工具做的直觀好用(參考我的文檔)。就像 Mike Muuss 提及到他自己的 ping程序：“要是我早知道這是我一生中最出名的成就，我就多開發(fā)一兩天，添加更多選項(xiàng)。”
- 高級(jí)語言：如果現(xiàn)有的 bcc 前端語言讓你很困擾，或許你能弄門更好的語言。要是你想將這門語言內(nèi)建到 bcc 里面，你需要使用 libbcc?；蛘吣憧梢詭椭? SystemTap BPF 或 ply 的工作。
- 整合圖形界面：除了 bcc 可以使用的 CLI 命令行工具，怎么讓這些信息可視呢?延遲熱點(diǎn)圖，火焰圖等等。
其它追蹤器
那么 SystemTap、ktap、sysdig、LTTng 等追蹤器怎么樣呢?它們有個(gè)共同點(diǎn)，要么使用了 BPF，要么在自己的領(lǐng)域做得更好。會(huì)有單獨(dú)的文章介紹它們自己。
至于 DTrace ?我們公司目前還在基于 FreeBSD 系統(tǒng)的 CDN 中使用它。
更多 bcc/BPF 的信息
我已經(jīng)寫了一篇《bcc/BPF 工具最終用戶教程》，一篇《bcc Python 開發(fā)者教程》，一篇《bcc/BPF 參考手冊(cè)》，并提供了一些有用的工具，每一個(gè)工具都有一個(gè) example.txt 文件和 man page。我之前寫過的關(guān)于 bcc 和 BPF 的文章有：
eBPF: One Small Step (后來就叫做 BPF)
bcc: Taming Linux 4.3+ Tracing Superpowers
Linux eBPF Stack Trace Hack (現(xiàn)在官方支持追蹤堆棧了)
Linux eBPF Off-CPU Flame Graph
Linux Wakeup and Off-Wake Profiling
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 4.9's Efficient BPF-based Profiler
我在 Facebook 的 Performance@Scale Linux BPF Superpowers 大會(huì)上發(fā)表過一次演講。十二月份，我將在 Boston 發(fā)表關(guān)于 BPF/bcc 在 USENIX LISA 方面的演講和教程。
致謝
- Van Jacobson 和 Steve McCanne，他們創(chuàng)建了最初用作過濾器的 BPF 。
- Barton P. Miller，Jeffrey K. Hollingsworth，and Jon Cargille，發(fā)明了動(dòng)態(tài)追蹤，并發(fā)表論文《Dynamic Program Instrumentation for Scalable Performance Tools》，可擴(kuò)展高性能計(jì)算協(xié)議 (SHPCC)，于田納西州諾克斯維爾市，1994 年 5 月發(fā)表。
- kerninst (ParaDyn, UW-Madison)，展示了動(dòng)態(tài)跟蹤的價(jià)值的早期動(dòng)態(tài)跟蹤工具(上世紀(jì) 90 年代后期)
- Mathieu Desnoyers (在 LTTng)，內(nèi)核的主要開發(fā)者，主導(dǎo) tracepoints 項(xiàng)目。
- IBM 開發(fā)的作為 DProbes 一部分的 kprobes，DProbes 在 2000 年時(shí)曾與 LTT 一起提供 Linux 動(dòng)態(tài)追蹤，但沒有整合到一起。
- Bryan Cantrill, Mike Shapiro, and Adam Leventhal (Sun Microsystems)，DTrace 的核心開發(fā)者，DTrace 是一款很棒的動(dòng)態(tài)追蹤工具，安全而且簡(jiǎn)單(2004 年)。對(duì)于動(dòng)態(tài)追蹤技術(shù)，DTrace 是科技的重要轉(zhuǎn)折點(diǎn)：它很安全，默認(rèn)安裝在 Solaris 以及其它以可靠性著稱的系統(tǒng)里。
- 來自 Sun Microsystems 的各部門的許多員工，促進(jìn)了 DTrace，為我們帶來了高級(jí)系統(tǒng)追蹤的意識(shí)。
- Roland McGrath (在 Red Hat)，utrace 項(xiàng)目的主要開發(fā)者，utrace 變成了后來的 uprobes。
- Alexei Starovoitov (PLUMgrid， 后來是 Facebook)，加強(qiáng)版 BPF(可編程內(nèi)核部件)的主要開發(fā)者。
- 那些幫助反饋、提交代碼、測(cè)試以及針對(duì)增強(qiáng)版 BPF 補(bǔ)丁(請(qǐng)?jiān)?lkml 搜索 BPF)的 Linux 內(nèi)核工程師： Wang Nan、 Daniel Borkmann、 David S. Miller、 Peter Zijlstra 以及其它很多人。
- Brenden Blanco (PLUMgrid)，bcc 的主要開發(fā)者。
- Sasha Goldshtein (Sela) 開發(fā)了 bcc 中的跟蹤點(diǎn)支持，和功能***大的 bcc 工具 trace 及 argdist，幫助 USDT 項(xiàng)目的開發(fā)。
- Vicent Martí 和其它 Github 上的工程師，為 bcc 編寫了基于 lua 的前端，幫助 USDT 部分項(xiàng)目的開發(fā)。
- Allan McAleavy、 Mark Drayton，和其他的改進(jìn) bcc 的貢獻(xiàn)者。
感覺 Netflix 提供的環(huán)境和支持，讓我能夠編寫 BPF 和 bcc 跟蹤器并完成它們。我已經(jīng)編寫了多年的追蹤工具(使用 TNF/prex、DTrace、SystemTap、ktap、ftrace、perf，現(xiàn)在是 bcc/BPF)，并寫書、博客以及評(píng)論，
***，感謝 Deirdré 編輯了另外一篇文章。
總結(jié)
Linux 沒有 DTrace(語言)，但它現(xiàn)在有了，或者說擁有了 DTraceTookit(工具)。
通過增強(qiáng)內(nèi)置的 BPF 引擎，Linux 4.9 內(nèi)核擁有了用來支持現(xiàn)代化追蹤的***一項(xiàng)能力。內(nèi)核支持這一最難的部分已經(jīng)做完了。今后的任務(wù)包括更多的命令行執(zhí)行工具，以及高級(jí)語言和圖形用戶界面。
對(duì)于性能分析產(chǎn)品的客戶，這也是一件好事：你能查看延遲柱狀圖和熱點(diǎn)圖，CPU 處理和 CPU 之外的火焰圖，擁有更好的時(shí)延斷點(diǎn)和更低耗的工具。在用戶空間按包跟蹤和處理是沒有效率的方式。
那么你什么時(shí)候會(huì)升級(jí)到 Linux 4.9 呢?一旦官方發(fā)布，新的性能測(cè)試工具就來了：apt-get install bcc-tools 。
開始享受它吧!
本文作者 Brendan Gregg 目前是 Netflix 的高級(jí)性能架構(gòu)師 ，他在那里做大規(guī)模計(jì)算機(jī)性能設(shè)計(jì)、分析和調(diào)優(yōu)。他是《Systems Performance》等技術(shù)書的作者，因在系統(tǒng)管理員方面的成績(jī)，獲得過 2013年 USENIX LISA 大獎(jiǎng)。他之前是 SUN 公司是性能領(lǐng)頭人和內(nèi)核工程師，研究存儲(chǔ)和網(wǎng)絡(luò)性能。他也發(fā)明和開發(fā)過一大波性能分析工具，很多已集成到操作系統(tǒng)中了 。
