Linux跟蹤工具：虛幻的肥皂鬧劇
Linux跟蹤工具在內核的發展就像是肥皂劇一樣，劇情婉轉，主題反復并且相互競爭。本文試圖總結當前Linux中眾多跟蹤工具現狀和歷史原因。
Attention: 編者對于以下內容并非親歷者(主要來自LWN和maillist)，如有歪曲請拍磚。以下部分雖屬八卦，但是，學習一些模塊的設計方案和歷史進程是我學習方法論的一部分，從這些糾結的方案和博弈中可以看到很多權衡和利弊幫助更好的獲得其中的思想，以下文字是連帶產物。學習使用這些性能工具推薦以下資源。
Why Trace the kernel?
很多人在接觸這類工具時可能會感到困惑，內核代碼早就已經優化的非常好了并且基本不會有什么Bug，那么為什么還需要插入這么多探針去查看內核的狀態？ 其實這種工具在生產環境中被很多人使用去跟蹤問題，比如系統此時無法理解的行為(CPU居高，IO忙)，這時候系統管理員需要利用這種工具在不干擾正常系統運作的情況下去Linux這個龐大的內核中查找原因。
Dtrace Envy和SystemTap
首先，我們先來介紹Dtrace Envy。Linux社區中過去有一個名詞叫Dtrace Envy，從字母上可以發現Linux社區對Dtrace的深惡痛絕，不僅是Dtrace在以前的Linux沒有相應如此強大的實現，而且Dtrace經常被Sun公司用來作營銷手段的噱頭(同樣的還有ZFS)與Linux進行對比。
那時還是07年，大家在提到Solaris系統時，Dtrace總是在人們關注的前幾個特征。而SystemTap當時還在幾個大公司Red Hat、Intel、IBM和日立內部使用，Dtrace的擁護者會嘲諷SystemTap只是個山寨貨，而SystemTap的粉絲認為SystemTap是個獨立發展的項目，并且以超越Dtrace為目標。
這兩個工具都是在內核中插入探針，當一個線程執行碰到探針時，預先定義的腳本(D語言腳本或者SystemTap腳本)就會運行。
Dtrace使用了大量的預先定義的探針插入到Solaris內核中，這種方式稱為靜態探針，這些探針都在Dtrace的文檔中做了詳述。并且一些簡單的通配符(*)可以用來實現多個探針的選擇。Sun宣稱無用的探針并不會增加太多的負載。
SystemTap沒有采用Dtrace的方式，估計是SystemTap沒有人有這么大精力去實現大量的靜態探針放到內核中(Linus會發飆的)。SystemTap采用的動態探針(kprobes實現）,它是在內核運行時被動態插入。SystemTap采用腳本語言來定義一些動作并且打開一些啟用的探針來(SystemTap的探針庫)插入到內核中，沒有用到的探針不會插入。
從上述的差異可以看到Dtrace的靜態探針是有優勢的，首先Dtrace大量的探針是被預定義并且可以被很好的文檔化(這對于系統管理員是非常好的，它們通常不熟悉內核源碼)，而SystemTap是可以在內核的任意位置，這就需要開發者需要熟悉內核的源碼并且把探針放到合適的位置。這就可能帶來安全性的問題，一些不恰當的探針放置是會帶來系統崩潰的(這種情況非常少)，即使非常少的位置是敏感的，但也足以使使用者感到不便，需要時時擔心可能的不恰當觸發。當然，SystemTap也有少量的預定義探針。
接著我們比較兩者的語言，Dtrace采用的D語言同樣繼承了安全的原則，它運行在虛擬機中并且帶有安全檢測，并且拒絕控制語句(只有三元操作符)，但在探針上可以附著表達式(相對于一個”if”)。而SystemTap同樣采取了大刀闊斧的姿態，不僅有完備的控制語句，SystemTap腳本(STP)直接翻譯成C，并且在SystemTap腳本中可以嵌入C。可以想象，在這里面如果出現了死循環就基本意味著crash了。
Kernel summit 2008的故事
08年，雖然SystemTap有了長足的發展，但是內核社區和SystemTap項目團隊仍然沒有一個很好的溝通和協商。SystemTap仍然沒有進入普通用戶的工具范疇，在kernel summit中，Matthew Wilcox表示Dtrace已經對Linux造成了足夠的威脅Ksummit-2008-discuss DTrace，Linux通常被認為是新技術的前沿，但是當Sun把Solaris開放后，一系列的新特征已經領先Linux，比如ZFS和Dtrace。
即使當時SystemTap和Btrfs被認為是Linux對抗的利器，但是，在社區還是有人對SystemTap表示失望，James Bottomley(iSCSI貢獻者)在郵件中提到Ksummit-2008-discuss DTrace，就好像在Winodws用戶期望在Linux有Outlook一樣，SystemTap只不過是Solaris用戶到Linux期望有一個一樣的工具，同時，James Bottomley表示SystemTap非常難用并且造成系統的崩潰。另一個Ted Ts’o同樣贊成SystemTap非常難以使用，但是他期望在SystemTap增加更多的”tapsets”來幫助對內核不熟悉的人更好的使用SystemTap。
SystemTap的開發者Frank Ch. Eigler表示SystemTap早已考慮性能、難以使用的問題并且正在解決中，他認為內核社區缺少與SystemTap團隊的溝通，并且提出了一系列的建議希望內核團隊參與到SystemTap與kernel的整合中來Frank Ch. Eigler fche at redhat.com。
但是，Ted Ts’o同樣回應稱SystemTap只會將”tapsets”的開發任務交給內核，而不去思考如何讓SystemTap變得易用并且更容易與內核整合，他同時指責SystemTap光想著讓企業發行版使用，而不去努力改善與內核的問題Theodore Tso tytso at mit.edu。
Frank Ch. Eigler表示大部分系統管理員是不會去使用SystemTap去思考內核的性能追蹤，SystemTap通常是被整合到PostgreSQL這種基礎軟件中來使用，因此，SystemTap更加注重對此類問題的解決。
同時，社區中有人期望把Dtrace移植到Linux中，但是這也困難重重，先不說Dtrace移植到Linux主線的技術問題，光光是CDDL協議就是不容于Linux的。好吧，接下來就是各種水友開始討論CDDL與GPL的協議問題(一群程序員開始Google。。。)
最后還是Linus強調了最重要的一點，這個同時也是針對utrace的:SystemTap的實現是不被內核開發者喜歡的，因為它創造、利用內核模塊的實現是不同于內核的，對于SystemTap的細節如鎖實現和使用等等都是off kernel的。它希望SystemTap在實現設計上能離內核越來越近。
ptrace
在介紹utrace之前首先需要介紹ptrace。它是Linux內核跟蹤工具的化石，過去(07年以前)很長一段時間里，大部分人利用它來調試應用或者內核模塊，但是它的問題也很多，低效(需要內核/用戶態切換)、實現難以維護(架構設計混亂)、用戶難以使用(接口復雜）、一個進程只能被一個進程跟蹤(使用信號方法跟蹤進程，信號使得目標只能wait一個進程)、會改變跟蹤進程的狀態(進程父子關系)、打斷系統調用并且一直有大量的安全問題存在。
ptrace的維護者在utrace出現之后就已經在呼吁讓ptrace基于utrace實現，因為ptrace代碼是混亂的，散亂在各個架構中，維護者早已經對橫跨多個架構的代碼厭倦了。
我們需要注意到gdb和strace都是基于ptrace，這個原因也導致了ustrace遲遲不能進入內核主線。
utrace
utrace在07年的時候進入內核的視線(Introducing utrace)，它的目的是完全取代ptrace在用戶態跟蹤的作用，utrace只是實現了一個在內核中的engine，它提供了一個框架供更多的人基于它來實現對用戶程序的控制任務(Trace,Debug,user-mode-linux)。
utrace的體系架構可以參考玩轉 utrace。
utrace自07年在LWN中提出，然后迅速沉寂消失在視線之外，在09又重新希望進入內核主線中，當時Red Hat和Fedora kernels其實已經支持utrace很多年了。utrace進入內核最重要的問題是在內核中沒有真正的用戶(以utrace為框架的實現)，utrace如果只是一個engine就沒有進入內核的必要。
Frank Eigler(utrace開發者)提供了ftrace(下面會提到)基于utrace的實現，但是內核認為這個實現只是個插件罷了，而另外一個utrace真正的用戶ptrace-over-utrace是被看做utrace進入內核的關鍵，但是有很多人以不成熟來反對，雖然ptrace有大量的ugly code并且難以維護但是畢竟已經存在這么多年了，取代ptrace是一個高風險的項目并且誰來做這個清理工作，如果不做清理工作兩者同時進入內核會帶來兩個ptrace實現帶來更多的問題，還有就是utrace并不是被所有架構支持，如果ptrace使用utrace的實現而刪除自己的實現在其他架構中(ARM和MIPS)就無法使用ptrace調用。并且ptrace-over-utrace如果想替代原來的ptrace實現，必須需要有一些killer features(通過utrace的框架還是能實現很多的)，Nesterov和McGrath這兩個ptrace的維護者站出來表示自己更愿意維護ptrace-over-utrace的方案，并且樂意去推出新的代碼。
問題之二是utrace會阻礙SystemTap進入內核(當時有很多人期望SystemTap盡快進入內核)，因為utrace沒有一個系統調用而是內核里的API(內核接口會不穩定)，SystemTap利用了utrace的許多ABI來實現用戶態的跟蹤，如果utrace進入內核，SystemTap在主線外可能就導致在用戶態跟蹤上一團糟(主線與非主線最重要的問題就是版本兼容性)并且需要尋找其他的方式。(PS:現在 systemtap 可以直接使用新的主流內核中的 kprobes 和基于 inode 的uprobes 機制，不再依賴非主流的 utrace 補丁。同時它也可以直接使用主流內核中的 perf 靜態探針 by agentzh)
在09年的Linux 2.6.30進入主線失敗后，utrace就準備好了長期在主線外的命運，Red Hat不得不承擔起utrace的維護任務并且長期在自己的內核中保持。目前來說，utrace和SystemTap像是一對難兄難弟。
LTTng
LTTng是另外一個動態跟蹤工具，它整合了內核和用戶態跟蹤，對于大量的跟蹤事件流有非常高的性能，并且有一系列的分析和抓取工具。
對于目前的Linux內核來說，LTTng只不過是眾多Tracing工具的一個，它制造了太多重復的工作比如Rring Buffer(內核中已經有兩個Ring buffer被perf和ftrace使用)，并且自己的系統調用接口(內核已經有此類的接口)，增加LTTng意味著更混亂的Tracing ABI在內核中。
相比較而言，LTTng進入內核比SystemTap和utrace更困難。
ftrace
相比前面的SystemTap、utrace和LTTng，ftrace就幸運多了。ftrace是用來幫助開發者和系統設計者尋找系統負載的原因，它可以用來調試和分析內核中的負載和性能原因。
ftrace之所以能順利進入內核中，主要還是因為它充分利用了內核中既有的設計和其他組件，它利用了debugfs、kprobes,uprobes等等，并且因為其簡單的靜態探針和安全性，ftrace的內核之路順利而平坦。
Tracepoint
tracepoint是在內核中預定義的一系列跟蹤點并且提供了hook讓使用者可以調用函數來進行分析，tracepoint在有probe attach時會在每次執行到tracepoint調用相應的函數。
tracepoint在08年的時候被置入內核中，ftrace也同樣使用tracepoint作為tracer使用。
kprobe
kprobes在Linux 2.6.9主線上實現，它主要在內核模塊中被使用，在模塊init 函數中安裝probe然后在exit時釋放。
更多的kprobe可以在Documents/kprobes.txt找到。
對于kprobe來說，更多的時候是被內核模塊開發者使用。因為kprobe比較麻煩且相對于SystemTap這類工具來說，kprobe只有較少的使用空間。
uprobe
實現了動態的介入用戶程序的運行并且不打斷的收集信息，它的原理與kprobe類似，都是在探針函數的第一個字節用breakpoint指令替代，當CPU運行到breakpoint指令時，uprobes得到通知并找到相應uprobe來執行對于的函數。
小結
目前Linux內核上眾多跟蹤、性能工具的實現其實非常混亂，像latencyTop、powertop、usbmon、blktrace都是好用的工具，但是每個工具都需要自己的hooks在內核，這對于內核而言是十分蛋疼的事情。而在Solaris中，powertop這類是在Dtrace之上實現的，不需要改變內核。
從Linux性能工具的發展可以看到，upstream kernel和商用kernel，其他系統(Solaris)的博弈和權衡是十分激烈的。對于Linux社區而言，Linus對于代碼的把控是十分必要的，在11年kernel summit之后，開發者已經普遍贊成收斂系統調用的增加，這對于LTTng,utrace的進入內核希望更小了。
