提到如何動態追蹤進程中的系統調用，相信大家第一時間都能想到 strace，它的基本用法非常簡單，非常適合用來解決 “為什么這個軟件無法在這臺機器上運行？” 這類問題。但如果需要分析線上服務 (特別是延遲敏感型)的某些系統調用的延遲時，strace 則不那么合適，因為它引入的開銷會非常大，從性能分析大師 Brendan Gregg 的測試結果得知，被 strace 追蹤的目標進程的運行速度會降低 100 倍以上，這對生產環境來說將是個災難。

那么是否有比較好用的工具用在生產環境上呢？答案是肯定的，下面將介紹兩款工具的常用命令，方便大家需要時查閱。

Perf

眾所周知，perf 是 Linux 系統下非常強大的性能工具，由 Linux 內核開發人員在不斷演進和優化。除了可以分析 PMU (Performance Monitoring Unit) 硬件事件，內核事件等通用功能外，perf 還提供了其他“子模塊”，比如 sched 分析調度器，timechart 根據負載特征可視化系統行為，c2c 分析可能存在的 false sharing (RedHat 在大量 Linux 的應用上，測試過這套 c2c 的開發原型，成功地發現了很多熱點的偽共享緩存行問題。)等，而 trace 則可用于分析系統調用，其功能非常強大，并保證了可以接受的開銷 —— 運行速度僅放慢 1.36 倍(dd 作為測試負載)。我們一起看下幾個常用的場景：

調用 syscall 數量的 top 排行榜

perf top -F 49 -e raw_syscalls:sys_enter --sort comm,dso --show-nr-samples

從輸出可以看到在采樣期間，kube-apiserver 的調用 syscall 的次數最多。

顯示超過一定延遲的系統調用信息

perf trace --duration 200

從輸出中可以看到進程名稱、pid ，超過 200 ms 的具體系統調用參數和返回值。

統計某個進程一段時間內系統調用的開銷

perf trace -p $PID -s

從輸出中可以看到各系統調用的次數，返回錯誤次數，總延遲，平均延遲等信息。

我們也可以進一步分析高延遲的調用棧信息

perf trace record --call-graph dwarf -p $PID -- sleep 10

對一組任務進行 trace

比如后臺有 2 個 bpf 工具在運行，我們想看下它們系統調用使用情況，就可以先將它們添加到 perf_event 這個 cgroup 下，再執行 perf trace：

mkdir /sys/fs/cgroup/perf_event/bpftools/
echo 22542 >> /sys/fs/cgroup/perf_event/bpftools/tasks
echo 20514 >> /sys/fs/cgroup/perf_event/bpftools/tasks
perf trace -G bpftools -a -- sleep 10

perf-trace 的使用就介紹到這里，更多的用法請參考 man 手冊，從上面可以看到 perf-trace 的功能非常強大，根據 pid 或 tid 就可以進行過濾。但似乎沒有對容器和 Kubernetes(K8s) 環境進行便捷的支持。不用著急，接下來介紹的這個工具就是針對容器和 K8s 環境的。

Traceloop

對于 Traceloop 大家可能有點陌生，但提到 BCC 想必大家就覺得熟悉了。BCC 的前端是 Python/C++，其所屬 iovisor 下還有一個項目叫 gobpf 是 BCC 的 go binding。而 Traceloop 則是基于 gobpf 庫進行開發的，此項目的主要目標應用場景是容器、K8s 環境。其原理比較簡單，其架構如圖所示：

核心步驟如下：

1. 利用 bpf helper 獲取 cgroup id，根據 cgroup id 而不是 pid、tid 進行過濾。

2. 每個 cgroup id 對應一個 bpf tail call，通過這種方式實現對此 cgroup id 對應的 perf ring buffer 進行寫入。

3. 用戶空間根據 cgroup id 讀取對應的 perf ring buffer。

需要注意的是，當前 cgroup id 的獲取方式是通過 bpf helper：bpf_get_current_cgroup_id 來獲取的，這個 id 是 cgroup v2 才有的。因此只適用于開啟了 cgroup v2 的環境。尚不確定此項目團隊是否有意向通過讀取 nsproxy 數據結構等方式來對 cgroup v1 進行支持，因此在這里只做簡單介紹。隨著 K8s 1.19 版本開始支持 cgroup v2，期待 cgroup v2 能盡快普及起來。以下使用 Centos 8 4.18 版本內核進行簡單的演示：在 traceloop 退出時 dump 系統調用信息

sudo -E ./traceloop cgroups --dump-on-exit /sys/fs/cgroup/system.slice/sshd.service

從輸出中可以看到，其輸出和 strace/perf trace 類似，只是針對 cgroup 進行過濾。需要注意的是 Centos 8 沒有像 Ubuntu 將 cgroup v2 掛載到 /sys/fs/cgroup/unified，而是直接掛載到 /sys/fs/cgroup 下，在使用前建議執行?mount -t cgroup2?來確定掛載信息。

對于 K8s 平臺，該團隊將 traceloop 集成到 Inspektor Gadget 項目中，通過 kubectl 插件來運行，由于管網給出詳細的 gif 示例，在這里就不做過多介紹了，對 cgroup v2 有需求的朋友可以試一試。

Benchmark

從 benchmark 結果看，strace 的引起的目標程序性能下降最大，perf trace 次之，traceloop 最小。

總結

strace 依然是解決 “為什么這個軟件無法在這臺機器上運行？” 相關問題的利器，但對于分析系統調用延遲等問題，perf trace 是合適的選擇，其也是基于 BPF 的實現，對于使用 cgroup v2 的容器、K8s 環境，traceloop 會更方便一些。

總結

以上是生活随笔為你收集整理的javamac系统通过pid获取进程名称_线上环境 Linux 系统调用追踪的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。