tracer 是一個高級的性能分析和診斷工具，但是不要讓這名詞唬住你，如果你使用過 strace 和tcpdump，其實你就已經使用過 tracer 了。系統 tracer 可以獲取更多的系統調用和數據包。它們通常能跟蹤任意的內核和應用程序。
有太多的
Linux tracer 可以選擇。每一種都有其官方的（或非官方的）的卡通的獨角獸吉祥物，足夠撐起一台"兒童劇"了。
那麼我們應該使用哪個 tracer 呢？
我會為兩類讀者回答這個問題，大部分人和性能/內核工程師。過一段時間這些可能會發生變化，我會持續跟進並補充，大概會一年更新一次。
多數人
多數人 (開發者，系統管理員，開發管理者，
運維人員，評測人員，等等) 不關心系統追蹤器的細節。下面是對於追蹤器你應該知道和做的：
1. 使用perf_events分析CPU性能
使用 perf_events 做 CPU 性能分析。性能指標可以使用 flame graph 等工具做可視化。
git clone --depth 1 https://github.com/brendangregg/FlameGraph
perf record -F 99 -a -g -- sleep 30
perf script | ./FlameGraph/stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl > perf.svg
Linux perf_events (又稱 "perf"，同命令名) 是 Linux 用戶的官方追蹤器和性能分析器。內置於內核代碼，有很好維護（近來獲得快速增強），通常通過 linux 命令行工具包添加。
perf 有很多功能，如果只能推薦一個，我選擇 CPU 性能分析。盡管這只是采樣，而不是從技術上追蹤事件。最難的部分是獲取完整的棧和信息，我為 java 和 node.js 做的一個演講 Linux Profiling at Netflix 中已經說過這個問題
2.了解其他的Tracer
正如我一個朋友說的：“你不需要知道如何操作 X 射線機器，但是一旦你吞了一枚硬幣，你得知道這得去做 X 射線”，你應該了解各種 tracer 都能做什麼，這樣就能在你工作中真正需要 tracer 的時候，你既可以選擇稍後學習使用，也可以雇相應的人來完成。
簡短來說：幾乎所有的東西都可以使用 tracer 來進行分析和跟蹤。如，文件系統，網絡處理器，硬件驅動器，全部的應用程序。可以看一下我的個人網站上關於 ftrace的文章，還有我寫的關於perf_events 文檔介紹，可以做為一個追蹤(或者性能分析)的例子。
3. 尋求前端支持工具
如果你正想買一個能支持跟蹤 Linux 的性能分析工具（有許多賣這類工具的公司）。想像一下，只需要直接點擊一下界面就能“洞察”整個系統內核，包括隱藏的不同堆棧位置的熱圖，我在Monitorama talk 中介紹了一個這樣帶圖形界面的工具。
我開源了一些我自己開發的前端工具，盡管只是 CLI （命令行界面）而不是（圖形界面）。這些工具也會讓人們更加快速容易的使用 tracer。比如下面的例子，用我的 perf_tool，跟蹤一個新進程:
# ./execsnoopTracing exec()s. Ctrl-C to end.
PID PPID ARGS
22898 22004 man ls
22905 22898 preconv -e UTF-8
22908 22898 pager -s
22907 22898 nroff -mandoc -rLL=164n -rLT=164n -Tutf8
[...]
在 Netflix 上，我們創建了一個 Vector，一個分析工具的實例同時也是 Linux 上的 tracer 的最終前端。
致性能或內核工程師
我們的工作變的越來越困難，很多的人會問我們怎麼樣去追蹤，哪種路徑可以用！為了正確理解一個路徑，你經常需要花上至少100個小時才能做到。理解所有的 linux 路徑去做出理性的決定是一個浩大的工程。（我可能是唯一一個接近做到這件事情的人）
這裡是我的建議，可以二選其一：
A) 選中一個全能的路徑，並且使它標准化，這將涉及花費大量的時間去弄清楚它在測試環境中的細微差別和安全性。我現在推薦 SystemTap 的最新版本（ie，從源代碼構建）。我知道有些公司已經選用 LTTng，而且他們用的很好，盡管它不是非常的強大（雖然它更安全）。Sysdig 可以成為另一個候選如果它可以增加追蹤點或者 kprobes。
B) 遵循我上面提供的流程圖，它將意味著盡可能更多的使用 ftrace 或者 perf_event， eBPF 會得到整合，之後其他的路徑像 SystemTap/LTTng 會去填補這個空白。 這就是我目前在 Netflix 做的工作。
1. ftrace
我喜歡用 ftrace，它是內核 hacker 的首選，內置於系統內核，可以使用跟蹤點(靜態檢查點)，能調用內核 kprobes 和 uprobes 調試工具。並且提供幾個這樣的功能：帶可選過濾器和參數的事件追蹤功能；在內核中進行統計的事件計數和定時功能；還有函數流程遍歷的功能。可以看一下內核代碼中 ftrace.txt 例子了解一下。ftrace 由 /sys 控制，僅支持單一的 root 用戶使用（但是你可以通過緩沖區實例破解以支持多用戶）。某些時候 Ftrace 的操作界面非常繁瑣，但是的確非常“hack”，而且它有前端界面。Steven Rostedt，ftace 的主要作者，創建了 trace-cmd 命令工具，而我創建了 perf 的工具集。我對這個工具最大的不滿就是它不可編程。舉例來說，你不能保存和獲取時間戳，不能計算延遲，不能把這些計算結果保存成直方圖的形式。你需要轉儲事件至用戶級別，並且花一些時間去處理結果。ftrace 可以通過 eBPF 變成可編程的。
2.perf_events
perf_events 是 Linux 用戶的主要跟蹤工具，它內置在內核源碼中，通常通過 linux-tools-commom 加入。也稱“perf”，同前端工具名稱，通常用來跟蹤和轉儲信息到一個叫做 perf.data 的文件中，perf.data 文件相當於一個動態的緩沖區，用來保存之後需要處理的結果。ftrace 能做到的，perf_events 大都也可以做到，perf-events 不能做函數流程遍歷，少了一點兒“hack”勁兒（但是對於安全/錯誤檢查有更好的支持）。它可以進行 CPU 分析和性能統計，用戶級堆棧解析，也可以使用對於跟蹤每行局部變量產生的調試信息。它也支持多用戶並發操作。和 ftrace 一樣也不支持可編程。如果要我只推薦一款 tracer，那一定是 perf 了。它能解決眾多問題，並且它相對較安全。
3. eBPF
extended Berkeley Packet Filter（eBPF）是一個可以在事件上運行程序的高效內核虛擬機（JIT）。它可能最終會提供 ftrace 和 perf_events 的內核編程，並強化其他的 tracer。這是 Alexei Starovoitov 目前正在開發的，還沒有完全集成，但是從4.1開始已經對一些優秀的工具有足夠的內核支持了，如塊設備I/O的延遲熱圖。可參考其主要作者 Alexei Starovoitov 的BPF slides和 eBPF samples。
4. SystemTap
SystemTap 是最強大的tracer。它能做所有事情，如概要分析，跟蹤點，探針，uprobes（來自SystemTap），USDT和內核編程等。它將程序編譯為內核模塊，然後加載，這是一種獲取安全的巧妙做法。它也是從tree發展而來，在過去有很多問題（多的可怕）。很多不是 SystemTap 本身的錯——它常常是第一個使用內核追蹤功能，也是第一個碰到 bug 的。SystemTap 的最新版本好多了（必須由源代碼編譯），但是很多人仍然會被早期版本嚇到。如果你想用它，可先在測試環境中使用，並與irc.freenode.net上 的 #systemtap 開發人員交流。（Netflix 有容錯機制，我們已經使用了 SystemTap，但是可能我們考慮的安全方面的問題比你們少。）我最大的不滿是，它似乎認為你有常常沒有的內核 debug 信息。實際上沒有它也能做很多事情，但是缺少文檔和例子（我必須自己全靠自己開始學習）。
5. LTTng
LTTng 優化了事件采集，這比其他 tracers 做得好。它從 tree 發展而來，它的核心很簡單：通過一組小規模的固定指令集將事件寫入追蹤緩沖區，這種方式使它安全、快速，缺點是它沒有內核編碼的簡單途徑。我一直聽說這不是一個大問題，因為盡管需要後期處理，它也已經優化到可以充分的度量。此外，它還首創了一個不同的分析技術，更多對所有關注事件的黑盒記錄將稍後以 GUI 的方式進行研究。我關心的是前期沒有考慮到要錄制的事件缺失問題如何解決，但我真正要做的是花更多時間來看它在實踐中用的怎麼樣。這是我花的時間最少的一個 tracer（沒有什麼特殊原因）。
6. Ktap
ktap 在過去是一款前景很好的 tracer，它使用內核中的 lua 虛擬機處理，在沒有調試信息的情況下在嵌入式設備上運行的很好。它分為幾個步驟，並在有一段時間似乎超過了 Linux 上所有的追蹤器。然後 eBPF 開始進行內核集成，而 ktap 的集成在它可以使用 eBPF 替代它自己的虛擬機後才開始。因為 eBPF 仍將持續集成幾個月，ktap 開發者要繼續等上一段時間。我希望今年晚些時候它能重新開發。
7. dtrace4linux
dtrace4linux 主要是 Paul Fox 一個人在業余時間完成的，它是 Sun DTrace 的 Linux 版本。它引入矚目，還有一些 provider 可以運行，但是從某種程度上來說還不完整，更多的是一種實驗性的工具（不安全）。我認為，顧忌到許可問題，人們會小心翼翼的為 dtrace4linux 貢獻代碼：由於當年 Sun 開源DTrace 使用的是 CDDL 協議，而 dtrace4linux 也不大可能最終進入 Linux kernel。Paul 的方法很可能會使其成為一個 add-on。我很樂意看到 Linux 平台上的 DTrace 和這個項目的完成，我認為當我加入 Netflix 後將會花些時間來協助完成這個項目。然而，我還是要繼續使用內置的 tracers，如 ftrace 和 perf_events。
8.OL DTrace
Oracle Linux DTrace為了將 DTrace 引入 Linux，特別是 Oracle Linux，做出了很大的努力。這些年來發布的多個版本表明了它的穩定進展。開發者們以一種對這個項目的前景看好的態度談論著改進 DTrace 測試套件。很多有用的 provider 已經完成了，如：syscall, pro
file, sdt, proc, sched 以及 USDT。我很期待 fbt（function boundary tracing, 用於內核動態跟蹤）的完成，它是 Linux 內核上非常棒的 provider。OL DTrace 最終的成功將取決於人們對運行 Oracle Linux（為技術支持付費）有多大興趣，另一方面取決於它是否完全開源：它的內核元件是開源的，而我沒有看到它的用戶級別代碼。
9. sysdig
sysdig是一個使用類tcpdump語法來操作系統事件的新tracer，它使用lua提交進程。它很優秀，它見證了系統跟蹤領域的變革。它的局限性在於它只在當前進行系統調用，在提交進行時將所有事件轉儲為用戶級別。你可以使用系統調用做很多事情，然而我還是很希望它能支持跟蹤點、kprobe和uprobe。我還期待它能支持eBPF做內核摘要。目前，sysdig開發者正在增加容器支持。留意這些內容。
原文：http://www.oschina.net/translate/choosing-a-linux-tracer
