Linux的各种监测、追踪诊断工具多而繁杂，而且学习其使用也是一个繁杂的过程，对新入门的人来说有点头大，那么有没有一个工具可以实现使用简洁明了，安装方便的工具呢？最近虫虫发现了还真有这样一款工具0x.tools，在此推荐给大家尝试使用，相信大家一定会喜欢。

概述

0x.tools是一组用于分析Linux上应用程序性能的开源实用程序。其目标是以最小依赖和最小安装实现对Linux系统的监测。0x.tools直接基于Linux内核中的新的eBPF模块，无需安装内核模块或繁重的监控框架，可以近乎零的成本来进行Linux的高效测控和故障排除。

0x.tools允许通过跟踪然后在正确的时间对正确的事件进行采样来测量单个线程级别的活动，例如执行的代码、睡眠状态、系统调用和等待位置。

eBPF充能

0x.tools 的工具集中新增加了一个明星工具xcapture-bpf 和xtop，其很像是老版的Linux top工具，但是基于Linux新内核eBPF功能实现系统x成像和从任何指定唯独角度查看性能数据的能力。可以使用它进行系统级概述，并深入了解各个线程的活动，甚至很快甚至可以深入了解各个内核事件，例如锁等待或内存停顿等。由于的eBPF不仅是可定制、可编程的性为xcapture-bpf提供对Linux系统的极大的洞察能力。

集中化明了显示

xcapture-bpf支持在一个单一终端屏幕通过分屏、文本搜索/高亮显示和线程数据滚动的形式，可以不用切换窗口或大量滚动，就可以实现相关应用堆栈跟踪的数据，所有更多相关的内容结构和关联性。

安装

xcapture-bpf（其他工具成熟）目前仍处于测试阶段，暂时不建议在生产系统上运行它。由于它使用eBPF（目前使用python3作为报告前端的 BCC），需要使用红帽系RHEL 8.1或deb系Ubuntu 24.04以及更新的系统。Ubuntu 22.04的BCC有一些内核头兼容性问题）并且20.04内核没有可用的所需eBPF功能。

在RHEL8上，可以使用以下命令安装先决条件：

sudo dnf install bcc bcc-tools python3 python3-bccgit clone github./tanelpoder/0xtools.gitls 0xtools/bin/xcapture-bpf*0xtools/bin/xcapture-bpf0xtools/bin/xcapture-bpf.ccat 0xtools/bin/xtop#!/usr/bin/bashCURDIR="$(dirname "$(realpath "$0")")"{CURDIR}/xcapture-bpf --xtop --clear-screen $*cd 0xtools/binsudo ./xtop

如果不想克隆/下载整个0xtools存储库，那么对于xcapture-bpf，只需下载上面列出的2个xcapture-bpf* 文件。无需编译.c文件，因为BCC工具集会即时处理它。xtop只是为了方便起见，一个简单的shell包装器。

安装成功有可以运行

sudo ./xcapture-bpf -o /tmp

它不会显示输出，而是记录每小时采集的所有样本threads_*.csv 文件并单独将任何新的、迄今为止未见过的（自xcapture启动以来）堆栈跟踪保存到 stacks_*.csv文件。 这最终将成为“始终在线”的系统范围活动深入分析方法的基础。可以使用grep/awk 任何选择的CSV处理技术来筛选时间段内的“热门”活动。

工具集合

将获得两类实用程序：

用于分析当前系统行为的实时交互工具。

低开销线程活动采样器，用于 对生产系统进行始终在线的低频分析 。 连续捕获的数据使您能够“回到过去”，甚至在间歇性问题第一次发生后（或期间）系统地对其进行故障排除。

命令

描述

PSN

通过采样/proc文件显示当前顶级线程活动

xcapture (v1)

低开销线程状态采样器和归档器读取/proc文件

xcapture bpf

构建低开销可编程线程状态采样器使用eBPF（测试版）

syscallargs

列出所有系统调用及其参数

schedlat

显示单个进程的CPU调度延迟占其运行时间的百分比

run_xcapture.sh

一个简单的“守护进程”脚本，用于保持 xcapture 运行

run_xcpu.sh

CPU线程的低频连续堆栈采样（使用perf）

xcapturev1是为了提高效率而用C编写的，它仅包含一个 C源文件和一个用于系统调用名称转换的头文件。所有其他工具都是Python或shell脚本。

用法

Linux 线程活动示例并在屏幕上显示固定宽度输出：

xcapture

对所有状态（包括休眠）的线程进行采样并将输出写入每小时的CSV文件中：

xcapture -a -o /data/xcap &

可以在命令行上“查询”线程活动历史记录以进行性能分析（或者只是将 CSV 加载到任何数据库中）：

可以使用标准shell文本处理工具栈对其进行查询分析查询：grep进行搜索，cut, awk对于分割取特段，uniq进行去重和分和sort进行排序（所有这些都可以用perl代替）。

比如一个典型的分析过程

cat 2020-10-13.01.csv | awk -F, '{ printf("%2s %-20s %-20s %s\n",$5,$4,$7,$10) }' | sort | uniq -c | sort -nbr | head -20

或者用

perl -lane ‘print “{$F[5] $F[3]4 $F[9]}”’ 2020-10-13.01.csv |sort| uniq -c | sort -nbr | head -20

当然可以使用一些csv工具来进行查询，比如一个有意思的工具q-text-as-data可以csv文件当sql语句查询：

q -d, -bTH 'select count(*) avgthr, username,st,syscall,wchanfrom 2020-10-13.01.csv group by username,st,syscall,wchanorder by 1 desc' | head -20

工具集和分析示例

和其他Linux标准工具一样，比如ps,top和lsof，capture v1，schedlat和psn 通过Linux /proc文件系统进行采样。/proc文件系统本质是一个内存盘，对Linux内核运行参数的文件映射。对其采集，无需要在安装任何额外的Linux 配置或任何奇特的东西。0x.tools只需需要Linux内核版本2.6或更高版本既可以运行。xcapture-bpf则需要最新内核的红帽系RHEL 8.1或deb系Ubuntu 24.04以及更新的版本。

Snapper

Linux Process Snapper 是一个Python脚本，用于解决当前正在发生的问题（无历史捕获）。直接从/proc报告的字段多于xcapture 捕获的字段（例如 IO 系统调用访问的文件名）。

IO瓶颈分析

“管道”的瓶颈是写入输出文件，而不是输入读：

psn -p 18286 -G syscall,filename

MySQL I/O瓶颈分析

由于频繁使用 fsync()，存在一些操作系统内核 inode 级别信号量争用：

sudo psn -p "mysqld|kwork" -G syscall,wchan

schedlat

显示单个进程的CPU调度延迟占其运行时间的百分比，比如：

./schedlat.py 29801

CPU调优

run_xcpu.sh打包perf工具，默认采用频率为1 Hz进行采样并分析。 run_xcpu.sh支持长期运行，而不会造成系统明显的性能开销。

cat bin/run_xcpu.sh...perf record -g -F 1 -a \--switch-output=1m \--timestamp-filename \--timestamp \-o $1/xcpu...

使用上述参数，perf 将采样的 CPU 堆栈跟踪写入1分钟粒度的文件中。

然后需要做的就是在具有正确时间戳的文件上运行perf，以放大性能问题的时间：

perf report -s sym,dso -i xcpu.2020101619323791

总结

0x.tools工具集成了一些了优秀的Linux测控和诊断跟踪工具，是系统运维们的瑞士军刀和百宝箱，尤其是基于新内核功能eBPF功能的高性能监控的充能，让其更是上一个台阶，当然其仓库星星从不到500今年徒增到1300就可以证明已经得到大家的关注。