eBPF 追踪实战：用 bpftrace 在生产环境找到那个慢请求

# 统计每个进程的 syscall 次数——就这么简单
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'

# Ubuntu/Debian
sudo apt-get install -y bpftrace

# CentOS/RHEL 8+
sudo dnf install -y bpftrace

# 验证安装
bpftrace --version
# bpftrace v0.21.0

# 查看你的内核支持哪些探针
sudo bpftrace -l 'tracepoint:syscalls:*' | head -20

# 1. 统计每个进程的 syscall 次数（找出谁在疯狂做系统调用）
sudo bpftrace -e '
tracepoint:raw_syscalls:sys_enter {
    @syscalls[comm] = count();
}'

# 输出示例：
# @syscalls[nginx]: 284721
# @syscalls[postgres]: 89432
# @syscalls[node]: 312897  ← 这家伙在干什么？

# 2. 追踪某个进程的所有 open() 调用（看它在打开什么文件）
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_openat /comm == "nginx"/ {
    printf("%s opened: %s\n", comm, str(args.filename));
}'

# 3. 统计新进程创建（谁在 fork 炸弹？）
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_execve {
    printf("%-6d %-16s %s\n", pid, comm, str(args.filename));
}'

# 4. 按进程统计磁盘 I/O 大小（谁在疯狂写磁盘）
sudo bpftrace -e '
tracepoint:block:block_rq_issue {
    @bytes[comm] = sum(args.bytes);
}'

# 5. 磁盘 I/O 延迟分布（直方图，单位微秒）
sudo bpftrace -e '
tracepoint:block:block_rq_issue { @start[args.dev, args.sector] = nsecs; }
tracepoint:block:block_rq_complete /@start[args.dev, args.sector]/ {
    @usecs = hist((nsecs - @start[args.dev, args.sector]) / 1000);
    delete(@start[args.dev, args.sector]);
}'

# 6. 追踪 TCP 连接建立（谁连了你的服务器）
sudo bpftrace -e '
kprobe:tcp_v4_connect {
    printf("%-6d %-16s → connecting...\n", pid, comm);
}
kretprobe:tcp_v4_connect /retval == 0/ {
    printf("%-6d %-16s → connected\n", pid, comm);
}'

# 7. 统计每个远端 IP 的 TCP 接收字节数
sudo bpftrace -e '
kprobe:tcp_recvmsg {
    @recv_bytes[ntop(((struct sock *)arg0)->__sk_common.skc_daddr)] = sum(arg2);
}'

# 8. 追踪进程被调度到哪个 CPU（NUMA 问题排查）
sudo bpftrace -e '
tracepoint:sched:sched_switch {
    printf("cpu%-2d: %-16s → %-16s\n",
           cpu, args.prev_comm, args.next_comm);
}' | head -50

# 9. 统计每个进程的运行队列等待时间（调度延迟）
sudo bpftrace -e '
tracepoint:sched:sched_wakeup { @qtime[args.pid] = nsecs; }
tracepoint:sched:sched_switch /@qtime[args.next_pid]/ {
    @usecs[args.next_comm] = hist((nsecs - @qtime[args.next_pid]) / 1000);
    delete(@qtime[args.next_pid]);
}'

# 10. 找出哪些进程在用 futex（锁竞争的信号）
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_futex {
    @futex[comm, args.op & 0xf] = count();
}'

# 测量 read() 系统调用的延迟分布
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_read {
    @start[tid] = nsecs;
}
tracepoint:syscalls:sys_exit_read /@start[tid]/ {
    @read_us = hist((nsecs - @start[tid]) / 1000);
    delete(@start[tid]);
}'

# 用 lhist() 看 0-1000us 范围内的精确分布
# lhist(value, min, max, step) - 线性分桶
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
tracepoint:syscalls:sys_exit_read /@start[tid]/ {
    @read_detail = lhist((nsecs - @start[tid]) / 1000, 0, 1000, 50);
    delete(@start[tid]);
}'

# 输出：每 50us 一个桶，看得更清楚
# [0, 50)     3241 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
# [50, 100)    187 |@@                                                  |
# [100, 150)    43 |                                                    |
# ...

# 哪个进程的 write() 延迟最高？
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_write { @start[tid] = nsecs; }
tracepoint:syscalls:sys_exit_write /@start[tid]/ {
    @write_us[comm] = hist((nsecs - @start[tid]) / 1000);
    delete(@start[tid]);
}'

# 输出会按进程名分组显示直方图：
# @write_us[nginx]:
# [0]             1241 |@@@@@@@@@@@@@@@@@@@@@@@@|
# [1]             2891 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
# ...
#
# @write_us[postgres]:
# [1]              342 |@@@@@@@@@@                                          |
# [2, 4)          1879 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
# [4, 8)          2341 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@      |
# ...  ← postgres 的 write 明显更慢，可能是 fsync

# 追踪 tcp_sendmsg：谁在发数据，发了多少字节
sudo bpftrace -e '
kprobe:tcp_sendmsg {
    // arg0 = struct sock *, arg2 = size
    @send_bytes[comm] = sum(arg2);
    @send_sizes[comm] = hist(arg2);
}

interval:s:5 {
    print(@send_bytes);
    clear(@send_bytes);
}'

# 每 5 秒打印一次统计，持续监控

#!/usr/bin/env bpftrace
// 文件：tcp_sendmsg_latency.bt
// 用途：测量 tcp_sendmsg 的执行时间，找出慢的 TCP 发送

kprobe:tcp_sendmsg
{
    @start[tid] = nsecs;
    @size[tid] = arg2;
}

kretprobe:tcp_sendmsg
/@start[tid]/
{
    $delta_us = (nsecs - @start[tid]) / 1000;
    $sz = @size[tid];

    // 只关注超过 100us 的慢调用
    if ($delta_us > 100) {
        printf("[SLOW] %-16s pid=%-6d size=%-6d latency=%dus\n",
               comm, pid, $sz, $delta_us);
    }

    @latency = hist($delta_us);
    @by_proc[comm] = hist($delta_us);

    delete(@start[tid]);
    delete(@size[tid]);
}

END
{
    // Ctrl+C 时清理临时 map，只保留直方图
    clear(@start);
    clear(@size);
}

sudo bpftrace tcp_sendmsg_latency.bt

# 输出：
# [SLOW] nginx            pid=1234   size=4096   latency=2341us
# [SLOW] nginx            pid=1234   size=8192   latency=5123us
# ^C  ← 按 Ctrl+C 查看汇总直方图

# 追踪 libc malloc 的分配大小分布
sudo bpftrace -e '
uprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc {
    @alloc_size = hist(arg0);
}
uprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc /arg0 > 1048576/ {
    printf("[BIG ALLOC] %-16s pid=%-6d size=%d bytes\n",
           comm, pid, arg0);
}'

# 找出谁在做大内存分配——这往往是 GC 压力或内存碎片的根因

# 追踪 OpenSSL 的 SSL_read 延迟（排查 TLS 握手和解密开销）
sudo bpftrace -e '
uprobe:/usr/lib/x86_64-linux-gnu/libssl.so.3:SSL_read {
    @start[tid] = nsecs;
}
uretprobe:/usr/lib/x86_64-linux-gnu/libssl.so.3:SSL_read /@start[tid]/ {
    @ssl_read_us[comm] = hist((nsecs - @start[tid]) / 1000);
    delete(@start[tid]);
}'

# 假设你有一个 HTTP server，想追踪 handle_request 函数
sudo bpftrace -e '
uprobe:/opt/myapp/server:handle_request {
    @start[tid] = nsecs;
}
uretprobe:/opt/myapp/server:handle_request /@start[tid]/ {
    $us = (nsecs - @start[tid]) / 1000;
    if ($us > 10000) {
        // 超过 10ms 的请求，打印调用栈
        printf("[SLOW REQUEST] %dus\n", $us);
        print(ustack);
    }
    @req_latency = hist($us);
    delete(@start[tid]);
}'

#!/usr/bin/env bpftrace
// 文件：offcpu.bt
// 用途：记录线程离开 CPU 到重新上 CPU 的时间 + 内核栈

tracepoint:sched:sched_switch
{
    // 记录被切走的线程的时间戳
    if (args.prev_state != 0) {
        // prev_state != 0 表示非自愿切换（被阻塞了）
        @off[args.prev_pid] = nsecs;
    }
}

tracepoint:sched:sched_switch
/@off[args.next_pid]/
{
    // 被切回来了，计算 off-cpu 时间
    $delta_us = (nsecs - @off[args.next_pid]) / 1000;

    // 只关注超过 1ms 的 off-cpu 事件
    if ($delta_us > 1000) {
        @stacks[kstack, comm] = sum($delta_us);
    }

    @off_cpu_us[comm] = hist($delta_us);
    delete(@off[args.next_pid]);
}

END
{
    clear(@off);
}

sudo bpftrace offcpu.bt

# 运行 30 秒后 Ctrl+C，查看结果
# @stacks 会显示哪些内核调用栈导致了长时间 off-CPU
# 常见的罪魁祸首：

# 1. 锁竞争
# schedule() → __schedule() → schedule_preempt_disabled()
#   → __mutex_lock_slowpath() → mutex_lock()  ← 等互斥锁
#   → your_function()

# 2. I/O 等待
# schedule() → io_schedule() → blk_mq_get_tag()
#   → __blkdev_direct_IO() → ext4_file_write_iter()  ← 等磁盘

# 3. 网络等待
# schedule() → sk_wait_data() → tcp_recvmsg()  ← 等对端数据

# 4. 页面错误
# schedule() → wait_on_page_locked()
#   → __do_page_fault()  ← 等页面从磁盘调入

# 第一步：用 bpftrace 收集 off-cpu 栈（折叠格式）
sudo bpftrace -e '
tracepoint:sched:sched_switch {
    if (args.prev_state != 0) { @off[args.prev_pid] = nsecs; }
}
tracepoint:sched:sched_switch /@off[args.next_pid]/ {
    $us = (nsecs - @off[args.next_pid]) / 1000;
    if ($us > 100 && args.next_comm == "myapp") {
        @[kstack] = sum($us);
    }
    delete(@off[args.next_pid]);
}' -d 2>/dev/null | grep -E "^@" > offcpu_stacks.txt

# 第二步：转换为火焰图（需要 FlameGraph 工具）
# git clone https://github.com/brendangregg/FlameGraph.git
cat offcpu_stacks.txt | \
    FlameGraph/stackcollapse-bpftrace.pl | \
    FlameGraph/flamegraph.pl \
        --title "Off-CPU Flame Graph" \
        --colors io \
        --countname "microseconds" \
    > offcpu_flamegraph.svg

# 低开销：tracepoint 触发频率低
sudo bpftrace -e 'tracepoint:block:block_rq_complete { @bytes = hist(args.bytes); }'
# 大约每秒触发几千次，开销 < 1%

# 中等开销：追踪高频系统调用
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_read { @[comm] = count(); }'
# 高负载下每秒触发几十万次，开销 1-5%

# 高开销（危险！）：追踪调度器事件
sudo bpftrace -e 'tracepoint:sched:sched_switch { @[kstack] = count(); }'
# 每秒触发几百万次 + 每次采栈，开销 10-30%
# 生产环境慎用！

# 检查你的内核版本
uname -r
# 5.15.0-92-generic  ← 这个版本支持 BTF 但不支持 kfunc

# 检查 BTF 支持
ls /sys/kernel/btf/vmlinux && echo "BTF supported" || echo "No BTF"

# 检查当前内核支持的 eBPF 特性
sudo bpftrace --info 2>/dev/null | head -30

# bpftrace 默认需要 root 或 CAP_BPF + CAP_PERFMON
# 不要把 bpftrace 的 suid 位设给普通用户！

# 推荐做法：用 capabilities 控制权限
sudo setcap cap_bpf,cap_perfmon=ep /usr/bin/bpftrace

# 或者用 unprivileged_bpf_disabled 限制非特权用户
cat /proc/sys/kernel/unprivileged_bpf_disabled
# 1 = 只有 root 可以加载 BPF 程序（推荐生产环境设置）
# 2 = 完全禁止非特权 BPF

# 调试 bpftrace 脚本本身——打印 AST 和 LLVM IR
sudo bpftrace -d -e 'kprobe:tcp_sendmsg { @[comm] = count(); }' 2>&1 | head -50

# 列出所有可用的 tracepoint
sudo bpftrace -l 'tracepoint:*' | wc -l
# 通常有 1800+ 个

# 查看某个 tracepoint 的参数结构
sudo bpftrace -lv 'tracepoint:syscalls:sys_enter_read'
# tracepoint:syscalls:sys_enter_read
#     int __syscall_nr;
#     unsigned int fd;
#     char * buf;
#     size_t count;

# 查看内核函数的参数（需要 BTF）
sudo bpftrace -lv 'kprobe:tcp_sendmsg'

# 监控你的 bpftrace 脚本对 CPU 的实际影响
# 在另一个终端运行：
pidstat -p $(pgrep -f bpftrace) 1
# 关注 %usr + %system，超过 5% 就要警惕

# 低采样频率的长期 CPU profiling（适合跑几小时）
sudo bpftrace -e 'profile:hz:49 /comm == "myapp"/ { @[kstack] = count(); }'

# 高采样频率的短期精确诊断（最多跑 30 秒）
sudo timeout 30 bpftrace -e 'profile:hz:999 /pid == 12345/ { @[ustack] = count(); }'

# 用 interval{} 定期清理 Map，防止无限增长
sudo bpftrace -e '
kprobe:tcp_sendmsg {
    @by_proc[comm] = sum(arg2);
}
interval:s:30 {
    print(@by_proc);
    clear(@by_proc);  // 每 30 秒清零重来
}'

# 推荐：用 -c 自动限定追踪范围和生命周期
sudo bpftrace -c '/opt/myapp/server --config prod.yaml' -e '
uprobe:/opt/myapp/server:handle_request {
    @start[tid] = nsecs;
}
uretprobe:/opt/myapp/server:handle_request /@start[tid]/ {
    @latency = hist((nsecs - @start[tid]) / 1000);
    delete(@start[tid]);
}'

# 危险：永远不要在生产这么干
# sudo bpftrace --unsafe -e '... system("rm -rf /something") ...'

# ❌ 错误：每个包都 printf，高负载下每秒几十万次输出
sudo bpftrace -e '
kprobe:tcp_sendmsg {
    printf("pid=%d comm=%s size=%d\n", pid, comm, arg2);  // 刷爆 ring buffer
}'

# ✅ 正确：用 Map 聚合，只在需要时打印
sudo bpftrace -e '
kprobe:tcp_sendmsg {
    @send[comm] = sum(arg2);
    @sizes[comm] = hist(arg2);
}
interval:s:5 {
    print(@send);
    clear(@send);
}'

# ❌ 错误：用 (pid, tid, kstack) 做 key，基数爆炸
sudo bpftrace -e '
tracepoint:sched:sched_switch {
    @[args.prev_pid, args.next_pid, kstack] = count();
    // 每一种 (prev_pid, next_pid, 内核栈) 组合都是一个 Map 条目
    // 跑几分钟后 Map 可能有几十万条目 → 内存暴涨 + 退出时打印卡死
}'

# ✅ 正确：降低 key 基数，只关注你需要的维度
sudo bpftrace -e '
tracepoint:sched:sched_switch /args.prev_comm == "myapp"/ {
    @[kstack] = count();  // 只按栈聚合，过滤特定进程
}'

# ❌ 错误：跑了 3 天的脚本，Map 里全是已经不存在的进程
sudo bpftrace -e '
tracepoint:raw_syscalls:sys_enter {
    @[comm, pid] = count();
    // pid 会不断新增（新进程），老的永远不删
}'

# ✅ 正确：定期快照并清理
sudo bpftrace -e '
tracepoint:raw_syscalls:sys_enter {
    @[comm, pid] = count();
}
interval:s:60 {
    print(@);
    clear(@);  // 每分钟重置，只看最近一分钟的活跃情况
}'

# ❌ 危险：__schedule 是内核最热的路径之一
sudo bpftrace -e 'kprobe:__schedule { @[kstack] = count(); }'
# 每次调度切换都采栈 → CPU 开销可达 20-30%

# ✅ 正确：加过滤条件，只追踪你关心的进程/场景
sudo bpftrace -e '
kprobe:__schedule /comm == "myapp"/ {
    @[kstack] = count();
}
interval:s:10 {
    print(@);
    clear(@);
}'
# 只追踪 myapp 的调度事件 → 开销从 20% 降到 < 1%