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

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

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

mage

幫助大家學習bpftrace，我創建了幾個“參考”

one-liners tutorial

reference guide

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

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

bpftrace/eBPF vs DTrace equivalency

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

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

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

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

mage

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

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

DTrace和bpftrace對比清單

如果你已經了解Dtrace，這里會花費你10分鐘時間，看看Dtrace和bpftrace之間的對比，這里列出主要的區別，截止到2018.08:

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

Dtrace和bpftrace的腳本對比

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

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

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

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

1. Linux isn't a company

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

2. Linux won

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

3. Most funding went into SystemTap

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

4. Good-enough solutions

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

5. CTF/BTF

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

默認安裝

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

Dtrace工具如何？

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

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

感謝

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

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

最后，感謝Netflix，它為我提供了一個很好的支持環境，幫助我開發和貢獻各種技術，包括BPF。

結局

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