内核追踪：ftrace、kprobe、uprobe、tracepoint 生产实战

某次生产故障：一个 Go 服务偶尔出现 200ms 的 fsync 延迟，但 prometheus-node-exporter 显示磁盘 I/O 正常，iostat 的 await 在 2ms 以内，strace 挂了 30 分钟没有捕捉到任何异常。最终通过 bpftrace 在 vfs_fsync_range 上挂 kprobe，发现延迟在特定时间点飙升——进一步分析是冷数据页 writeback（回写）在 fsync 前被强制触发。

这个案例说明：用户态可观测性工具能覆盖多数问题，但内核调度延迟、文件系统写回、网络栈丢包、内存回收等路径，只能在「内核算账」层面捕获。内核追踪不是日常工具；当 Metrics、Logs、Traces、Profile 都「正常」而用户仍报障时，它是工具箱里的最后一层。

本文聚焦 SRE 排障路径：如何用 ftrace、tracepoint、kprobe、uprobe、bpftrace 在可控开销下定位问题。eBPF 编程与 CO-RE 工程路径见 eBPF 可观测性全景；网络子系统 tracepoint 与 sk_buff 路径解剖见 Linux 网络子系统 · 内核网络追踪工具箱——本系列不重复 netfilter/tcp 栈源码级拆解。

实验环境说明（A 级，本机实测）：WSL2，内核 6.6.87.2-microsoft-standard-WSL2，debugfs 已挂载于 /sys/kernel/debug（需 root）。下文 ftrace 与 tracepoint 命令在本环境执行过；bpftrace、perf、trace-cmd 未安装——相关片段标注为「需在具备 BTF 的 Linux 物理机/VM 上复现」，不伪造命令输出。

一、Linux 内核追踪技术栈全景

1.1 四条演进阶段

1.2 四层架构

1.3 与 Metrics / Logs / Traces 的协作

内核追踪在 事故复盘剧本 链条中位于 Profile 之后：

flowchart LR
  A[Alert] --> B[Metrics RED]
  B --> C[Logs trace_id]
  C --> D[Traces 慢 span]
  D --> E[Profile 火焰图]
  E --> F{用户态仍无法解释?}
  F -->|是| G[ftrace / bpftrace]
  F -->|否| H[变更关联 Events]

1.4 开销量级（文献与工程经验，非本环境 benchmark）

二、ftrace：内核自带的函数追踪器

2.1 debugfs 前置条件

ftrace 接口位于 debugfs，路径 /sys/kernel/debug/tracing/。

# 检查是否已挂载（WSL/部分云镜像默认未挂载）
mount | grep debugfs

# 若不存在，需 root 挂载
sudo mount -t debugfs none /sys/kernel/debug

# 验证 tracing 目录
ls /sys/kernel/debug/tracing/available_tracers

WSL2 上普通用户访问会 Permission denied——文中所有 ftrace 操作均假设 sudo 或 CAP_SYS_ADMIN。

2.2 function tracer：按函数过滤

比 function_graph 更轻量，适合先看「哪些进程在调某个 syscall」：

cd /sys/kernel/debug/tracing
echo 0 > tracing_on
echo nop > current_tracer
echo "__x64_sys_read" > set_ftrace_filter
echo function > current_tracer
echo 1 > tracing_on
sleep 1
echo 0 > tracing_on
head -30 trace

以下输出经删减，来自本环境 WSL2 实测：

# tracer: function
#
# entries-in-buffer/entries-written: 30/30   #P:24
#
#                                _-----=> irqs-off/BH-disabled
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| / _-=> migrate-disable
#                              |||| /     delay
#           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
#              | |         |   |||||     |         |
            init-377     [006] .....  2374.430358: __x64_sys_read <-x64_sys_call
           sleep-14275   [014] .....  2374.430369: __x64_sys_read <-x64_sys_call
           sleep-14275   [014] .....  2374.430535: __x64_sys_read <-x64_sys_call
            node-1324    [023] .....  2374.536801: __x64_sys_read <-x64_sys_call
      containerd-721     [010] .....  2374.794246: __x64_sys_read <-x64_sys_call

解读：TASK-PID 列显示调用方（如 node-1324、containerd-721）；FUNCTION 列显示 __x64_sys_read <-x64_sys_call 表示从系统调用入口进入 read 实现。

2.3 function_graph tracer：调用链耗时

定位 write() / fsync() 内核路径上哪一步最慢：

cd /sys/kernel/debug/tracing
echo 0 > tracing_on
echo nop > current_tracer
echo > set_graph_function   # 清空
echo "ext4_file_write_iter" > set_graph_function
echo function_graph > current_tracer
echo 1 > tracing_on
sleep 5
echo 0 > tracing_on
head -50 trace

输出格式示例（结构说明，非本机 ext4 实测——WSL 默认文件系统可能为 ext4 或 9p，函数名因 FS 而异）：

 0)               |  __x64_sys_write() {
 1)   0.421 us    |    security_file_permission();
 2)   2.103 us    |    vfs_write();
 3)              |    vfs_write() {
 4)   8.552 us    |      ext4_file_write_iter();
 5)              |      ext4_file_write_iter() {
 6)  45.231 us    |        ext4_da_write_begin();
 7)  12.004 us    |        ext4_da_write_end();
 8)              |      }
 9)              |    }
10)   0.312 us    |  }

数字列为该函数体内耗时（微秒）。ext4_da_write_begin 异常偏大时，结合 Continuous Profiling 与块设备 tracepoint 继续下钻。

2.4 安全脚本：限时 + 自动恢复

#!/bin/bash
# ftrace-safe-capture.sh — 生产必备：超时自动关闭
set -euo pipefail
TRACING=/sys/kernel/debug/tracing
FUNC=${1:?usage: $0 <kernel_function>}
DURATION=${2:-30}

cleanup() {
  echo 0 > "$TRACING/tracing_on" 2>/dev/null || true
  echo nop > "$TRACING/current_tracer" 2>/dev/null || true
}
trap cleanup EXIT INT TERM

echo 0 > "$TRACING/tracing_on"
echo nop > "$TRACING/current_tracer"
echo "$FUNC" > "$TRACING/set_graph_function"
echo function_graph > "$TRACING/current_tracer"
echo 1 > "$TRACING/tracing_on"
sleep "$DURATION"
cat "$TRACING/trace" | head -500

2.5 trace-cmd 与 KernelShark

trace-cmd 将 ftrace 采集封装为 trace.dat，KernelShark 提供 GUI 时间线。本 WSL 环境未安装 trace-cmd；在 Ubuntu 22.04+ 物理机：

sudo apt install trace-cmd kernelshark
sudo trace-cmd record -e sched:sched_switch sleep 5
trace-cmd report

2.6 ftrace histogram（无需 eBPF）

内核内置直方图触发器，适合 syscall 延迟分布：

# 示例：read syscall 延迟直方图（需内核支持 hist trigger）
echo "hist:keys=common_pid:vals=lat:sort=lat:lat=common_lat_us" > \
  /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger
sleep 10
cat /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/hist
echo "!hist:keys=common_pid" > /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger

若 trigger 文件不存在，说明内核未启用对应 hist 支持——退而使用 bpftrace 或 perf。

三、tracepoint：内核的稳定 API

3.1 与 kprobe 的本质区别

3.2 浏览与启用

ls /sys/kernel/debug/tracing/events/sched/
cat /sys/kernel/debug/tracing/events/sched/sched_switch/format

sched_switch format 片段（本环境实测）：

name: sched_switch
ID: 324
format:
    field:unsigned short common_type;   offset:0;   size:2; signed:0;
    field:char prev_comm[16];   offset:8;   size:16;    signed:0;
    field:pid_t prev_pid;   offset:24;  size:4; signed:1;
    field:char next_comm[16];   offset:40;  size:16;    signed:0;
    field:pid_t next_pid;   offset:56;  size:4; signed:1;

启用单个 CPU 上的 sched_switch：

echo 1 > /sys/kernel/debug/tracing/events/sched/sched_switch/enable
sleep 2
echo 0 > /sys/kernel/debug/tracing/events/sched/sched_switch/enable

3.3 关键子系统 tracepoint 速查

3.4 用 ftrace 直接消费 tracepoint

cd /sys/kernel/debug/tracing
echo 0 > tracing_on
echo nop > current_tracer
echo 'sched:sched_switch' >> set_event
echo 1 > tracing_on
sleep 3
echo 0 > tracing_on
head -20 trace
echo > set_event   # 清除

3.5 bpftrace 挂 tracepoint（复现步骤，非本环境输出）

# 安装（Ubuntu 22.04+ 示例）
sudo apt install bpftrace linux-headers-$(uname -r)

# 块设备 I/O 延迟直方图
sudo bpftrace -e '
tracepoint:block:block_rq_issue { @start[args->dev] = nsecs; }
tracepoint:block:block_rq_complete {
  $t = nsecs - @start[args->dev]; @lat_us = hist($t / 1000);
}' -d 10

-d 10 表示 10 秒后自动退出并打印 map——生产安全必备。

四、kprobe：挂内核函数的动态探针

4.1 工作原理

x86 上用 int3 替换目标函数入口指令；命中后执行 BPF 程序或 ftrace 回调，再恢复原指令继续执行。

4.2 bpftrace 语法

sudo bpftrace -e 'kprobe:vfs_fsync_range { @start[tid] = nsecs; }
 kretprobe:vfs_fsync_range /@start[tid]/ { @fsync_us = hist((nsecs - @start[tid]) / 1000); }' -d 30

4.3 生产安全边界

优先 tracepoint；kprobe 仅挂低频路径；禁止在 tcp_rcv_established、__schedule、_raw_spin_lock 等热路径长期挂载。

4.4 与 fentry/fexit 的选择

内核 ≥ 5.5 且目标函数支持时，eBPF 全景 推荐 fentry/fexit 替代 kprobe——开销约为一半。

4.5 版本差异

不同内核版本函数可能改名或内联；bpftrace -l 'kprobe:*write*' 列出可用符号后再挂。

五、uprobe：用户态函数的动态追踪

5.1 适用场景

遗留 C 服务无 metrics、追踪 malloc/free、OpenSSL SSL_write 明文（HTTPS 可观测）。

5.2 容器路径问题

uprobe 需要宿主机上二进制绝对路径，如 /var/lib/docker/overlay2/<id>/merged/usr/bin/app。

5.3 Go 1.17+ 调用约定

寄存器传参导致 bpftrace 默认 arg0 读取失效；需查 Go 版本对应文档或使用 USDT。

5.4 USDT 优先

Python python:function__entry、MySQL mysql:query__start 等比盲目 uprobe 更稳定。

5.5 示例

sudo bpftrace -e 'uprobe:/usr/lib/x86_64-linux-gnu/libc.so.6:malloc { @bytes = hist(arg1); }' -d 15

六、bpftrace：内核追踪的高级语言

6.1 一分钟上手

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s %s\n", comm, str(args->filename)); }' -d 5

6.2 内置变量

pid, tid, uid, comm, nsecs, cpu, arg0–arg3（架构相关）。

6.3 Map 类型

@count[key], @hist(val), @dist[key]——内核态聚合，减少 ring buffer 压力。

6.4 生产模板

始终 -d duration；按 pid/comm 过滤；输出量过大时改用 @count 而非 printf。

6.5 BTF 依赖

CONFIG_DEBUG_INFO_BTF=y；缺失时 bpftrace 无法解析 args-> 结构体字段。检查：ls /sys/kernel/btf/vmlinux。

七、perf 与持续剖析产品

7.1 perf 定位

正式性能采集、火焰图、perf stat 硬件计数；bpftrace 适合 ad-hoc 探索。

7.2 常用命令

sudo perf top
sudo perf record -g -p $(pidof myapp) sleep 30
sudo perf script | stackcollapse-perf.pl | flamegraph.pl > out.svg

7.3 与 Parca/Pixie

Continuous Profiling 用 eBPF 持续采样；手工 bpftrace 用于事故窗口临时加深。

7.4 K8s DaemonSet 权限

最小权能：CAP_BPF, CAP_PERFMON, CAP_SYS_ADMIN（部分内核仅需前两者）——避免 privileged: true。

八、内核追踪的生产安全模型

8.1 限时三件套

timeout、bpftrace -d、trap cleanup 脚本。

8.2 白名单 attach 点

平台团队维护允许的 tracepoint/kprobe 列表；on-call 只能跑白名单脚本。

8.3 ring buffer 溢出

事件丢失时 bpftrace 打印 Lost N events——需减小 printf 或加强过滤。

8.4 变更窗口

内核追踪视为变更：需工单、on-call 值守、可回滚。

8.5 审计

记录谁在哪个节点跑了什么脚本、持续多久——与 Events 变更关联 对齐。

九、决策树与工具选择

9.1 快速决策

9.2 与 strace 对比

strace 用 ptrace，开销数量级更高；仅适合短窗口单进程，不适合生产。

9.3 与网络篇边界

TCP 重传根因、kfree_skb reason 枚举见 linux-net 追踪工具箱；本篇只引用 tcp_retransmit_skb 作为「该看内核了」的信号。

十、工程坑点

10.1 function_graph 无过滤

全内核函数追踪 → 节点不可用，真实事故模式。

10.2 kprobe 挂不可重入函数

特定锁路径可能导致死锁——仅短时、低频。

10.3 容器内 uprobe 路径错误

挂容器内路径失败；必须解析 overlay 合并层路径。

10.4 WSL debugfs 权限

普通用户无法访问；且部分 tracing 特性在虚拟化内核上受限。

10.5 BTF 缺失

发行版 linux-image-generic 无 BTF 包时需装 linux-image-$(uname -r)-dbgsym。

10.6 追踪忘记关闭

交班 checklist 必须含 cat /sys/kernel/debug/tracing/tracing_on 应为 0。

十一、落地清单

11.1 平台能力

• debugfs 挂载 playbook
• bpftrace/perf 标准镜像
• BTF 内核包纳入基线
• 白名单脚本库 Git 管理

11.2 on-call

• 事故 playbook 含「内核层」升级条件
• 限时脚本一键执行
• 与 SLO Dashboard 同屏观察

11.3 合规

• 追踪操作审计日志
• 生产追踪需工单
• 禁止全量 function_graph

十二、与 eBPF 全景和 linux-net 的阅读边界

12.1 本系列覆盖

SRE 排障：何时下钻内核、用哪种 attach、如何控风险、如何与 Metrics/Logs/Traces 串联。

12.2 14 篇覆盖

bcc/bpftrace/libbpf 工程路径、CO-RE、verifier、Pixie/DeepFlow 产品化。

12.3 linux-net 覆盖

网络 tracepoint 字段、skb_drop_reason、per-function 网络火焰图。

12.4 15 篇覆盖

用户态网络可观测：eBPF flow、Service Mesh、DNS——不替代内核 syscall 延迟分析。

十三、关键概念回顾

十四、常见误解

十五、下一步

内核追踪是 eBPF 与内核部分的收束篇。治理层从 SLO 工程 开始。排障全链路见 事故复盘剧本。

附录 A：WSL2 复现 checklist

1. sudo mount -t debugfs none /sys/kernel/debug
2. 验证 available_tracers 含 function_graph
3. ftrace 过滤脚本跑通（§2.2 实测输出）
4. 安装 bpftrace：sudo apt install bpftrace（可选，物理机推荐）
5. 检查 BTF：ls /sys/kernel/btf/vmlinux

附录 B：sched_switch 延迟分析思路

高 sched_switch 频率 + 单进程 comm 长时间不运行 → CPU 竞争或 cgroup CPU 限流。 结合 cgroup v2 cpu.max 与 Metrics 中 container_cpu_cfs_throttled_seconds_total。 bpftrace 模板：tracepoint:sched:sched_wakeup 与 sched_switch 配对算 runqueue 延迟。

附录 C：块设备延迟与 iostat 对照

iostat -x 的 await 是聚合值；tracepoint 可看 per-device、per-process。 当 await 正常但应用 fsync 慢 → 查 ext4 writeback、journal 提交路径。

附录 D：文件系统 fsync 剧本

1. Metrics：节点 disk write 吞吐正常？
2. Trace：ext4_sync_file_enter/exit 延迟
3. kprobe：vfs_fsync_range kretprobe hist
4. 若 writeback → 查 dirty_ratio、 cgroup memory 压力

附录 E：syscall 热点 bpftrace 脚本库

# 按 comm 统计 openat 次数
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @opens[comm] = count(); }' -d 10
# 按进程统计 read 字节
sudo bpftrace -e 'tracepoint:syscalls:sys_exit_read /args->ret > 0/ { @bytes[comm] = sum(args->ret); }' -d 10

附录 F：K8s 节点追踪 Job 模板

apiVersion: batch/v1
kind: Job
metadata:
  name: bpftrace-capture
spec:
  template:
    spec:
      hostPID: true
      restartPolicy: Never
      containers:
      - name: bpftrace
        image: quay.io/iovisor/bpftrace:latest
        securityContext:
          privileged: false
          capabilities:
            add: [SYS_ADMIN, BPF, PERFMON]
        command: ["bpftrace", "-e", "...", "-d", "30"]
        volumeMounts:
        - name: debugfs
          mountPath: /sys/kernel/debug
      volumes:
      - name: debugfs
        hostPath:
          path: /sys/kernel/debug

附录 G：权限与 capabilities 对照

附录 H：perf_event_paranoid 调优

cat /proc/sys/kernel/perf_event_paranoid
# 2=仅 root 可内核采样；1=允许用户态；0=允许内核；-1=无限制
# 生产节点常用 2，追踪 Job 用专用 SA

附录 I：与 12-profiling 的分工

Profiling：用户态采样、pprof、语言 runtime。 本篇：内核路径、syscall、块设备、调度。 连续运行用 16-continuous-profiling。

附录 J：事故案例：cgroup CPU 限流

现象：p99 抖动，CPU Metrics 显示未打满。 根因：cgroup cpu.max 导致 throttling，sched_switch 显示长时间等待。 修复：调整 quota 或 HPA；补充 throttled_seconds 告警。

附录 K：排障场景速查表

十六、完整排障剧本：fsync 200ms 尖刺

16.1 阶段 0：确认问题形状（用户态）

结论：进入内核层。

16.2 阶段 1：块设备 tracepoint（bpftrace，需 BTF 环境）

sudo bpftrace -e '
tracepoint:block:block_rq_issue { @t[args->dev, pid] = nsecs; }
tracepoint:block:block_rq_complete {
  $k = args->dev;
  @blk_us[$k, comm] = hist((nsecs - @t[$k, pid]) / 1000);
  delete(@t[$k, pid]);
}' -d 60

若块设备直方图尾部正常，排除纯磁盘硬件问题。

16.3 阶段 2：ext4 / fsync 路径

cd /sys/kernel/debug/tracing
echo "ext4_sync_file_enter" >> set_event
echo "ext4_sync_file_exit" >> set_event
echo 1 > tracing_on
sleep 30
echo 0 > tracing_on
grep ext4_sync trace | tail -20

16.4 阶段 3：kprobe 量化 vfs_fsync_range

sudo bpftrace -e '
kprobe:vfs_fsync_range { @s[tid] = nsecs; }
kretprobe:vfs_fsync_range /@s[tid]/ {
  @us = hist((nsecs - @s[tid]) / 1000); delete(@s[tid]);
}' -d 120

若 p99 尖刺与 writeback 相关，查 dirty_bytes、/proc/vmstat 中 nr_dirty。

16.5 与 linux-net 篇的边界

若怀疑网络而非磁盘：用 tcp_retransmit_skb 计数（本篇仅作入口），重传原因与 sk_buff 路径见 linux-net 追踪工具箱。

十七、perf 火焰图工作流（命令模板）

本 WSL 未安装 perf；以下为物理机/云主机标准流程，未标注实测输出。

# 安装
sudo apt install linux-perf-$(uname -r | cut -d- -f1-2)

# 记录 30s 调用栈
sudo perf record -F 99 -g -p $(pidof myapp) -- sleep 30
sudo perf script | stackcollapse-perf.pl | flamegraph.pl > /tmp/app.svg

与 Profiling 中 pprof 火焰图对照：perf 偏内核+用户态合计，pprof 偏语言 runtime。

十八、内核追踪脚本白名单治理

平台团队维护 sre-tracing-scripts Git 仓库，on-call 仅允许执行 tagged release：

scripts/
  block-io-latency.bt      # tracepoint block_rq
  fsync-hist.bt            # kprobe vfs_fsync_range
  syscall-read-latency.bt  # sys_enter/exit read
  tcp-retrans-count.bt     # 入口级，细节见 linux-net
POLICY.md                  # 最长 120s、禁止 function_graph 无过滤

CI 检查：脚本必须含 -d 或文档说明限时方式；禁止 current_tracer=function_graph 且无 set_graph_function。

十九、tracepoint 分类目录（排障索引）

19.1 sched

用途：CPU 调度、饥饿

ls /sys/kernel/debug/tracing/events/sched/

19.2 syscalls

用途：syscall 入口

ls /sys/kernel/debug/tracing/events/syscalls/

19.3 block

用途：块 I/O 延迟

ls /sys/kernel/debug/tracing/events/block/

19.4 ext4

用途：ext4 日志与 fsync

ls /sys/kernel/debug/tracing/events/ext4/

19.5 tcp

用途：TCP 重传（详见过 net 篇）

ls /sys/kernel/debug/tracing/events/tcp/

19.6 kmem

用途：内核分配风暴

ls /sys/kernel/debug/tracing/events/kmem/

19.7 vmscan

用途：内存回收压力

ls /sys/kernel/debug/tracing/events/vmscan/

二十、与 eBPF 产品化方案的衔接

eBPF 可观测性全景 第 3–5 节讲 bcc/bpftrace/libbpf 工程路径；本篇是 SRE 手持脚本 层。

二十一、bpftrace 食谱库（需 BTF，限时 -d）

21.1 按进程统计 read 字节

sudo bpftrace -e 'tracepoint:syscalls:sys_exit_read /args->ret > 0/ { @b[comm] = sum(args->ret); }' -d 30

21.2 统计 TCP connect 失败

sudo bpftrace -e 'kretprobe:tcp_connect /retval < 0/ { @err[comm] = count(); }' -d 30

21.3 统计 runqueue 延迟

sudo bpftrace -e 'tracepoint:sched:sched_wakeup { @q[comm] = nsecs; } tracepoint:sched:sched_switch /@q[comm]/ { @runq_us = hist((nsecs - @q[comm]) / 1000); }' -d 30

21.4 统计 major fault

sudo bpftrace -e 'tracepoint:exceptions:page_fault_user { @maj[comm] = count(); }' -d 30

21.5 容器过滤示例

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat /cgroup == 12345/ { @o[comm] = count(); }' -d 30

二十二、常见生产违规与替代方案

二十三、专题 1

主题：cgroup v2 cpu.max 与 sched 延迟

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

二十四、专题 2

主题：memcg OOM 前 vmscan tracepoint

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

# 交班检查
for n in $(seq 0 $(nproc)); do
  echo -n "cpu$n: "; cat /sys/kernel/debug/tracing/tracing_on 2>/dev/null || echo N/A
done

二十五、专题 3

主题：overlayfs 与容器内文件路径

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

二十六、专题 4

主题：NFS 客户端慢路径 tracepoint

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

二十七、专题 5

主题：io_uring 与传统 read/write 对比

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

# 交班检查
for n in $(seq 0 $(nproc)); do
  echo -n "cpu$n: "; cat /sys/kernel/debug/tracing/tracing_on 2>/dev/null || echo N/A
done

二十八、专题 6

主题：journald 与 rsyslog 对 I/O 的影响

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

二十九、专题 7

主题：透明大页 THP 与延迟尖刺

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

三十、专题 8

主题：NUMA 远程内存访问 perf NUMA 计数

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

# 交班检查
for n in $(seq 0 $(nproc)); do
  echo -n "cpu$n: "; cat /sys/kernel/debug/tracing/tracing_on 2>/dev/null || echo N/A
done

三十一、专题 9

主题：软锁 softlockup 与 ftrace graph

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

三十二、专题 10

主题：rcu_sched 延迟（极端场景）

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

三十三、专题 11

主题：eBPF verifier 拒绝时的降级 ftrace

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

# 交班检查
for n in $(seq 0 $(nproc)); do
  echo -n "cpu$n: "; cat /sys/kernel/debug/tracing/tracing_on 2>/dev/null || echo N/A
done

三十四、专题 12

主题：内核模块 vs eBPF 追踪选型

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

三十五、专题 13

主题：ARM64 与 x86_64 kprobe 差异

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

三十六、专题 14

主题：RHEL 与 Ubuntu BTF 包名对照

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

# 交班检查
for n in $(seq 0 $(nproc)); do
  echo -n "cpu$n: "; cat /sys/kernel/debug/tracing/tracing_on 2>/dev/null || echo N/A
done

三十七、专题 15

主题：AKS/GKE 节点镜像 tracing 权限

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

三十八、专题 16

主题：SELinux enforcing 下 debugfs

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

三十九、专题 17

主题：审计d 与追踪共存

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

# 交班检查
for n in $(seq 0 $(nproc)); do
  echo -n "cpu$n: "; cat /sys/kernel/debug/tracing/tracing_on 2>/dev/null || echo N/A
done

四十、专题 18

主题：on-call 交班 tracing_on 检查

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

四十一、专题 19

主题：与 13-events 变更窗口联动

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

四十二、专题 20

主题：内核追踪实验记录模板

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

# 交班检查
for n in $(seq 0 $(nproc)); do
  echo -n "cpu$n: "; cat /sys/kernel/debug/tracing/tracing_on 2>/dev/null || echo N/A
done

四十三、专题 21

主题：SRE 面试题：为何不用 SystemTap

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

四十四、专题 22

主题：课堂练习：解释 ftrace 输出列含义

要点：结合 Continuous Profiling 与 Metrics 交叉验证；任何内核实验需工单与限时。

练习：在 staging 用 §2.2 命令采集 1s __x64_sys_read trace，标出 3 个不同 comm。

内核追踪专题 0

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 1

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 2

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 3

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 4

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 5

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 6

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 7

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 8

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 9

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 10

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 11

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 12

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 13

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 14

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 15

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 16

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 17

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 18

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 19

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

内核追踪专题 20

对照 14-ebpf-overview 与 linux-net 追踪工具箱；生产追踪需工单+限时。

参考资料

1. Linux Kernel, Documentation/trace/ftrace.rst
2. Linux Kernel, Documentation/trace/tracepoints.rst
3. B. Gregg, BPF Performance Tools, Addison-Wesley, 2019
4. bpftrace Reference Guide, https://github.com/bpftrace/bpftrace/blob/master/docs/reference_guide.md
5. man perf_event_open(2), https://man7.org/linux/man-pages/man2/perf_event_open.2.html
6. 本站 eBPF 可观测性全景
7. 本站 linux-net 内核网络追踪工具箱
8. 本站 Continuous Profiling
9. 本站 Profiling
10. 本站 网络可观测性

上一篇：Continuous Profiling：持续剖析架构与落地

下一篇：SLO 工程：错误预算、Burn Rate、多窗口多燃烧率告警