我第一次提及 bpftrace (aka BPFtrace)工作計劃，是在曾經(jīng)的一次演講上：DTrace for Linux 2016， 當(dāng)時，我也介紹了Linux Kernel的eBPF的孵化過程，同時也介紹了我當(dāng)時在做的bcc (BPF Complier Collection)項目，一個讓我在新的架構(gòu)上重寫Dtrace工具集的項目。bcc雖然很強(qiáng)大，但是要實現(xiàn)一個小工具就需要寫一個小腳本，還是有點(diǎn)小麻煩（寫一個小腳本要寫的代碼太多，不能用一行命令表達(dá)），因此，我準(zhǔn)備額外分享另外一個高級工具bpftrace給大家。bpftrace特點(diǎn)在于，當(dāng)希望編寫小工具的時候，可以一行命令表達(dá)完整。

我，Willian Gaspar, 和 Matheus Marchini，也提供了一些拓展和bugfix的patch，查看沒有處理的問題issue list，查看指南， 查看之前的提交。

bpftrace使用了已有的Linux kernel中的基礎(chǔ)設(shè)施（eBPF, kprobes, uprobes, tracepoints, perf_events），同時也有bcc的庫，至于bpftrace內(nèi)部實現(xiàn)，使用了 lex/yacc parser 把程序轉(zhuǎn)化為AST，再到 llvm IR actions, 最后變成BPF。

mage

幫助大家學(xué)習(xí)bpftrace，我創(chuàng)建了幾個“參考”

one-liners tutorial

reference guide

bpftrace的“單行命令手冊” 是基于 FreeBSD DTrace Tutorial， 我覺得這是一個非常高效的方法去學(xué)習(xí)bpftrace。

自從我?guī)椭鷧⑴c開發(fā)bpftrace，我發(fā)現(xiàn)我也會時不時的引入一些bugs，可能bpftrace會SIGSEGV，或者，coredump？也許吧，我們已經(jīng)盡力的修復(fù)了好多這些問題。也有可能bpftrace會輸出一些因為和LVM 或者 BPF verifier不兼容，不適配導(dǎo)致的錯誤提示（用-v了）？
如果是的話，請讓我知曉，也許bpftrace會讓kernel panic？呵呵，這個很少很少了，我都沒有見過，自從使用了eBPF組件到現(xiàn)在這么多年來。如果出現(xiàn)了用戶態(tài)的bugs，bpftrace的crash或者stuck，hang之類的，需要被killed才可以的情況，請在github上提交一個issue，讓我們也知道此事，當(dāng)然，如果你可以，也歡迎你可以幫我們修復(fù)這些bug。bpftrace到現(xiàn)在我們的測試集里已經(jīng)有200多個test case了。

bpftrace/eBPF vs DTrace equivalency

這一個章節(jié)，我會寫一些“例子”，來對比“bpftrace/eBPF” 和 “Dtrace”，但是，注意一點(diǎn)，并不是說kernel中的eBPF就是僅僅實現(xiàn)了一個 “Linux版的Dtrace” 哦，eBPF還有很多的用處。

eBPF是其作者 Alexei Starovoitov 在PLUMgrid工作的時候（現(xiàn)在在Facebook）創(chuàng)建，是打算做成一個 Kernel中 通用的 “虛擬機(jī)”的，可以幫助實現(xiàn)軟件定義網(wǎng)絡(luò)的場景。很明顯，它還有很多其他的場景，比如：eXpress Data Path, container security and networking, iptables, infrared decoding, intrusion detection, hyperupcalls, 和 FUSE performance. 實際上，eBPF直接使用是很費(fèi)勁的，所以，才產(chǎn)生了bcc上層的python庫。

bpftrace就是希望可以成為一個更加高級的，可以達(dá)到“手到擒來”的工具，bpftrace參考了Dtrace的實現(xiàn)，我們已經(jīng)往bpftrace中添加了很多功能，我也知道，我們還沒有做到Dtrace的所有功能，比如：custom aggregation printing, shell arguments, translators, sizeof(), speculative tracing, and forced panic，我們現(xiàn)在添加的，只是我們現(xiàn)在需要的。

Dtrace同樣也并不是包含了bpftrace的所有功能，比如：bpftrace的參數(shù)，可以在shell中使用，如果有些功能bpftrace做不到，那就用bcc，它們的關(guān)系就像是:

mage

它會打印那些分配但是沒有被釋放的fd的user-level stacks, 它是在分配fd的時候保存棧信息，在free fd的時候，將對應(yīng)的棧信息刪除。當(dāng)bpftrace退出的時候，它會打印剩下的@ alloc_stack: 也就是沒有被釋放掉的fd的stack信息。我還寫了一個更長的腳本，包含了timestamp信息的，所以我抓取更長的數(shù)據(jù)，你可以將這個技術(shù)復(fù)用到任何一種object分配的場景，或者給你自己的泄漏檢測工具增添色彩。如果是Dtrace，這需要dump出所有的stacks到一個文件中，然后事后處理，這個會引起更大的處理開銷。eBPF可以在kernel中做這些事情，在kernel中對數(shù)據(jù)進(jìn)行過濾，這樣效率更高。

還有一個更重要的案例，在我的另外一個文章off-wake time中有所展示。

DTrace和bpftrace對比清單

如果你已經(jīng)了解Dtrace，這里會花費(fèi)你10分鐘時間，看看Dtrace和bpftrace之間的對比，這里列出主要的區(qū)別，截止到2018.08:

這個清單當(dāng)然沒有羅列bpftrace的所有的功能，比如 access aggregation elements, user-level tracing system wide, save stacks as variables, 更多可以看這里reference_guide

Dtrace和bpftrace的腳本對比

將功能從Soloris上移植到Linux上的主要工作可不是簡簡單單的語法上移植，而是研究和測試以找到等效的Linux跟蹤點(diǎn)及其參數(shù)。主要的工作與追蹤語言無關(guān)。

既然我移植了它到Linux上，但是我覺得有點(diǎn)奇怪。我猜想這就回答了一個問題：磁盤在尋找嗎？但它實際上回答了一個棘手的問題：應(yīng)用程序是否導(dǎo)致磁盤搜索？我在2004年寫了seeksize.d，所以我必須回想一下那個時候才能理解它。當(dāng)時，我已經(jīng)可以通過解釋iostat（1）輸出來判斷磁盤是否正在尋找：看到高磁盤延遲，但I(xiàn)/O很小。iostat（1）無法告訴我的是，這是因為使用磁盤的應(yīng)用程序相互競爭，還是應(yīng)用程序本身正在應(yīng)用隨機(jī)工作負(fù)載。這就是我寫的seeksize.d要回答的問題，一個指導(dǎo)進(jìn)一步優(yōu)化的答案：您是需要在不同的磁盤上分離應(yīng)用程序，還是調(diào)整一個應(yīng)用程序的磁盤工作負(fù)載。

為何我花那么久時間做這件事?

我曾經(jīng)告訴很多工程師和一些公司關(guān)于做一個在Linux上的高級trace工具，我認(rèn)為這個是Linux商業(yè)環(huán)境下一個比較有趣的課題，所以，我才花那么長的時間來完成它:

1. Linux isn't a company

在開發(fā)DTrace時，Sun Microsystems的首席執(zhí)行官Scott McNealy喜歡說“一箭雙雕”。如此之多，以至于員工們曾經(jīng)在他的辦公室窗戶上安裝了一個巨大的箭頭，就像愚人節(jié)的笑話一樣。在Linux中，所有的工作都沒有落后于一個跟蹤箭頭，而是分成14個（systemtap、lttng、ftrace、perf_events、dtrace4linux、oel dtrace、ktap、sysdig、intel pin、bcc、shark、ply和bpftrace）。如果Linux是一家公司，管理層可以合并重疊的項目，并專注于一個或兩個跟蹤程序。但事實并非如此。

2. Linux won

Linux放棄了自己的動態(tài)跟蹤實現(xiàn)（DProbes，2000年），為Sun創(chuàng)造了一個開發(fā)自己的競爭特性的機(jī)會。Sun擁有數(shù)十億的收入，無數(shù)員工致力于使DTrace成功（包括銷售、營銷、教育服務(wù)等），Linux不存在這種情況。Linux已經(jīng)贏了，而且沒有公司提供任何真正的資源來構(gòu)建一個有競爭力的跟蹤程序，只有一個例外：RedHat。

3. Most funding went into SystemTap

詢問一位RHEL客戶有關(guān)Dtrace的情況，他們可能會說他們幾年前就有了：systemtap。然而，SystemTap從來沒有完全合并到Linux內(nèi)核中（部分是這樣的，比如uprobes），所以作為一個脫離樹的項目，它需要維護(hù)才能工作，而RedHat只為RHEL做了這一點(diǎn)。作為一個Ubuntu用戶，試著向RedHat抱怨：他們經(jīng)常會說“切換到RHEL”。你能怪他們嗎？問題是，這是唯一真正的錢在桌上建立一個LinuxDTrace（特別是自從紅帽拿起曾經(jīng)Sun公司的帳戶，誰想要DTrace），它進(jìn)入了SystemTap。

4. Good-enough solutions

另一個障礙是足夠好的解決方案。一些公司已經(jīng)知道如何讓SystemTap（或LTTNG、FTrace或Perf）工作得足夠好，并且很高興。他們希望ebpf/bcc/bpftrace完成嗎？當(dāng)然。但它們不會幫助開發(fā)它們，因為它們已經(jīng)有了足夠好的解決方案。一些公司很樂意使用我的ftrace性能工具或我的BCC工具，所以我自己以前的工程工作給了他們一個不幫助構(gòu)建更好的東西的理由。

5. CTF/BTF

Dtrace是在Solaris上構(gòu)建的，它已經(jīng)有了緊湊的類型格式來提供所需的結(jié)構(gòu)信息。Linux有dwarf和debuginfo，與ctf不同的是，它并不常見。這阻礙了開發(fā)真正的類似DTrace的跟蹤器。直到最近，在Linux4.18版本中，我們是否已經(jīng)有了Linux:BPF類型格式（BTF）的CTF技術(shù)。

默認(rèn)安裝

值得一提的是，Dtrace是Solaris上的默認(rèn)安裝。這確實有助于采用，因為客戶沒有選擇！現(xiàn)在想象一下，要使bpftrace成為所有Linux發(fā)行版上的默認(rèn)安裝，需要做什么。我認(rèn)為這是一個長期的嘗試，這意味著Linux可能永遠(yuǎn)不會擁有與Solaris上DTrace相同的體驗。但這是一個可以幫助您的領(lǐng)域：請讓您的發(fā)行版維護(hù)人員在默認(rèn)情況下包括bpftrace（加上bcc和sysstat）。這些是危機(jī)工具，通常用于分析遇到緊急性能問題的系統(tǒng)，安裝它們的時間（“apt-get-update；apt-get-install…”）可能意味著問題在您有機(jī)會看到之前就消失了。

Dtrace工具如何？

僅僅因為Linux有了ebpf，并不能使dtrace一夜之間成為一個糟糕的工具。它在擁有它的操作系統(tǒng)上仍然有用，并且任何具有它的操作系統(tǒng)都可以很好地為將來升級到ebpf做好準(zhǔn)備，ebpf可以重用內(nèi)部組件，比如提供者工具。工作已經(jīng)開始將ebpf帶到bsd，bpf就是在那里產(chǎn)生的。

值得讓那些花時間學(xué)習(xí)dtrace的人放心的是，我不認(rèn)為時間浪費(fèi)了。使用dtrace或bpftrace最困難的部分是知道如何處理它，遵循解決問題的方法。一旦你進(jìn)入了一些復(fù)雜軟件的內(nèi)部，對于一個緊迫的生產(chǎn)問題，無論你輸入quantize（）還是hist（）都是最不重要的問題。在調(diào)試dtrace的問題時，也可以幫助bpftrace。

感謝

bpftrace是由 Alastair Robertson創(chuàng)建的項目，同時在eBPF和bcc項目中做了大量的貢獻(xiàn)，可以看看DTrace for Linux 2016 里的感謝部分有另外對Dtrace和早期的tracing工作的對其他人的貢獻(xiàn)和鳴謝。如果您在使用的是bpftrace，您使用了Alexei Starovoitov在（ebpf）中開發(fā)的代碼、包括：Brendan Blanco（libbpf）、我自己、Sasha Goldshtein（USDT）和其他人開發(fā)的大量代碼。有關(guān)代碼的lib庫疑問，請參閱bcc。Facebook還有許多工程師在BPF和BCC上工作，他們使其成為當(dāng)今成熟的技術(shù)。

bpftrace本身有一種類似Dtrace的語言，以及awk和c。這不是eBPF上高級語言的第一次嘗試：第一次是由Jovi Zangwei開發(fā)的Shark，然后是Tobais Waldekranz開發(fā)的ply，然后由Alastair Robertson開發(fā)的bpftrace。甚至在某種程度上，Richard Henderson正在開發(fā)基于eBPF作為SystemTap的后端的工作。感謝所有從事這些工作的人，以及我們使用的所有其他技術(shù)。

最后，感謝Netflix，它為我提供了一個很好的支持環(huán)境，幫助我開發(fā)和貢獻(xiàn)各種技術(shù)，包括BPF。

結(jié)局

自從四年前eBPF開始并入內(nèi)核以來，它改變了Linux跟蹤技術(shù)的格局。我們現(xiàn)在有了lib、tools和為eBPF構(gòu)建的high-level front-end：bpftrace。bpftrace是性能分析利器，可以幫助您分析其他工具做不到的事情。它是對BCC的補(bǔ)充：BCC非常適合于復(fù)雜的工具，而bpftrace非常適合于“一行可以表達(dá)的命令”(one-liners)。在這篇文章中，我描述了bpftrace以及它如何與Dtrace進(jìn)行比較。在我的下一篇文章中，我將更加關(guān)注bpftrace。