提到如何動(dòng)態(tài)追蹤進(jìn)程中的系統(tǒng)調(diào)用，相信大家第一時(shí)間都能想到 strace，它的基本用法非常簡單，非常適合用來解決 “為什么這個(gè)軟件無法在這臺(tái)機(jī)器上運(yùn)行？” 這類問題。但如果需要分析線上服務(wù) (特別是延遲敏感型)的某些系統(tǒng)調(diào)用的延遲時(shí)，strace 則不那么合適，因?yàn)樗氲拈_銷會(huì)非常大，從性能分析大師 Brendan Gregg 的測(cè)試結(jié)果得知，被 strace 追蹤的目標(biāo)進(jìn)程的運(yùn)行速度會(huì)降低 100 倍以上，這對(duì)生產(chǎn)環(huán)境來說將是個(gè)災(zāi)難。

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

Perf

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

調(diào)用 syscall 數(shù)量的 top 排行榜

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

從輸出可以看到在采樣期間，kube-apiserver 的調(diào)用 syscall 的次數(shù)最多。

顯示超過一定延遲的系統(tǒng)調(diào)用信息

perf trace --duration 200

從輸出中可以看到進(jìn)程名稱、pid ，超過 200 ms 的具體系統(tǒng)調(diào)用參數(shù)和返回值。

統(tǒng)計(jì)某個(gè)進(jìn)程一段時(shí)間內(nèi)系統(tǒng)調(diào)用的開銷

perf trace -p $PID -s

從輸出中可以看到各系統(tǒng)調(diào)用的次數(shù)，返回錯(cuò)誤次數(shù)，總延遲，平均延遲等信息。

我們也可以進(jìn)一步分析高延遲的調(diào)用棧信息

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

對(duì)一組任務(wù)進(jìn)行 trace

比如后臺(tái)有 2 個(gè) bpf 工具在運(yùn)行，我們想看下它們系統(tǒng)調(diào)用使用情況，就可以先將它們添加到 perf_event 這個(gè) cgroup 下，再執(zhí)行 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 的使用就介紹到這里，更多的用法請(qǐng)參考 man 手冊(cè)，從上面可以看到 perf-trace 的功能非常強(qiáng)大，根據(jù) pid 或 tid 就可以進(jìn)行過濾。但似乎沒有對(duì)容器和 Kubernetes(K8s) 環(huán)境進(jìn)行便捷的支持。不用著急，接下來介紹的這個(gè)工具就是針對(duì)容器和 K8s 環(huán)境的。

Traceloop

對(duì)于 Traceloop 大家可能有點(diǎn)陌生，但提到 BCC 想必大家就覺得熟悉了。BCC 的前端是 Python/C++，其所屬 iovisor 下還有一個(gè)項(xiàng)目叫 gobpf 是 BCC 的 go binding。而 Traceloop 則是基于 gobpf 庫進(jìn)行開發(fā)的，此項(xiàng)目的主要目標(biāo)應(yīng)用場(chǎng)景是容器、K8s 環(huán)境。其原理比較簡單，其架構(gòu)如圖所示：

核心步驟如下：

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

2. 每個(gè) cgroup id 對(duì)應(yīng)一個(gè) bpf tail call，通過這種方式實(shí)現(xiàn)對(duì)此 cgroup id 對(duì)應(yīng)的 perf ring buffer 進(jìn)行寫入。

3. 用戶空間根據(jù) cgroup id 讀取對(duì)應(yīng)的 perf ring buffer。

需要注意的是，當(dāng)前 cgroup id 的獲取方式是通過 bpf helper：bpf_get_current_cgroup_id 來獲取的，這個(gè) id 是 cgroup v2 才有的。因此只適用于開啟了 cgroup v2 的環(huán)境。尚不確定此項(xiàng)目團(tuán)隊(duì)是否有意向通過讀取 nsproxy 數(shù)據(jù)結(jié)構(gòu)等方式來對(duì) cgroup v1 進(jìn)行支持，因此在這里只做簡單介紹。隨著 K8s 1.19 版本開始支持 cgroup v2，期待 cgroup v2 能盡快普及起來。以下使用 Centos 8 4.18 版本內(nèi)核進(jìn)行簡單的演示：在 traceloop 退出時(shí) dump 系統(tǒng)調(diào)用信息

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

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

對(duì)于 K8s 平臺(tái)，該團(tuán)隊(duì)將 traceloop 集成到 Inspektor Gadget 項(xiàng)目中，通過 kubectl 插件來運(yùn)行，由于管網(wǎng)給出詳細(xì)的 gif 示例，在這里就不做過多介紹了，對(duì) cgroup v2 有需求的朋友可以試一試。

Benchmark

從 benchmark 結(jié)果看，strace 的引起的目標(biāo)程序性能下降最大，perf trace 次之，traceloop 最小。

總結(jié)

strace 依然是解決 “為什么這個(gè)軟件無法在這臺(tái)機(jī)器上運(yùn)行？” 相關(guān)問題的利器，但對(duì)于分析系統(tǒng)調(diào)用延遲等問題，perf trace 是合適的選擇，其也是基于 BPF 的實(shí)現(xiàn)，對(duì)于使用 cgroup v2 的容器、K8s 環(huán)境，traceloop 會(huì)更方便一些。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。