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

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

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

mage

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

one-liners tutorial

reference guide

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

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

bpftrace/eBPF vs DTrace equivalency

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

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

bpftrace就是希望可以成為一個(gè)更加高級(jí)的，可以達(dá)到“手到擒來(lái)”的工具，bpftrace參考了Dtrace的實(shí)現(xiàn)，我們已經(jīng)往bpftrace中添加了很多功能，我也知道，我們還沒(méi)有做到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

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

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

DTrace和bpftrace對(duì)比清單

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

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

Dtrace和bpftrace的腳本對(duì)比

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

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

為何我花那么久時(shí)間做這件事?

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

1. Linux isn't a company

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

2. Linux won

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

3. Most funding went into SystemTap

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

4. Good-enough solutions

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

5. CTF/BTF

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

默認(rèn)安裝

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

Dtrace工具如何？

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

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

感謝

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

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

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

結(jié)局

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