2. ftrace核心概念：tracepoint、kprobe、uprobe、function tracer的工作原理与区别
ftrace 作为 Linux 内核内置的跟踪框架，其底层依赖多种不同的探测机制来捕获内核与用户空间的行为。理解 tracepoint、kprobe、uprobe 和 function tracer 的工作原理与适用场景，是掌握 ftrace 实战技能的基础。本章将逐一剖析这四种核心机制，并通过对比表格和内联 SVG 图帮助读者建立清晰的概念体系。
2.1 四种核心机制总览
下表从稳定性、动态性、性能开销和典型用途四个维度，对四种机制进行快速对比：
| 机制 | 稳定性 | 动态插桩 | 性能开销 | 典型用途 |
|---|---|---|---|---|
| tracepoint | 高（内核 ABI 稳定） | 否（静态定义） | 极低（条件跳转） | 系统调用、调度、网络事件 |
| kprobe | 中（依赖内核版本） | 是（任意指令地址） | 中（断点 + 模拟） | 内核函数参数/返回值、指令级调试 |
| uprobe | 中（依赖用户态符号） | 是（用户态任意地址） | 中（断点 + 模拟） | 用户态函数跟踪、性能热点分析 |
| function tracer | 高（ftrace 框架内置） | 是（函数粒度） | 低（mcount/fentry 调用） | 内核函数调用图、延迟分布 |
2.2 tracepoint：静态稳定的观测点
tracepoint 是内核开发者预先定义在关键代码路径中的静态探测点。每个 tracepoint 在编译时被插入一个条件跳转指令，默认情况下该跳转不执行，因此开销几乎为零。只有当用户通过 ftrace 或 perf 等工具激活该 tracepoint 时，内核才会执行注册的处理函数。
- 定义位置：
include/trace/events/目录下的头文件。 - 激活方式： 写入
/sys/kernel/tracing/events/<子系统>/<事件>/enable。 - 优势： 接口稳定，不随内核内部实现变化而改变，适合长期监控。
- 局限： 只能跟踪已预埋的事件点，无法覆盖所有内核代码。
# 激活所有系统调用 tracepoint
echo 1 > /sys/kernel/tracing/events/syscalls/enable
# 查看可用的 tracepoint 列表
ls /sys/kernel/tracing/events/format 文件描述了每个事件的字段布局，使用 cat /sys/kernel/tracing/events/sched/sched_switch/format 可查看具体字段。
2.3 kprobe：动态内核探测
kprobe 允许在任意内核指令地址动态插入探测点，无需重新编译内核。其工作原理是在目标地址写入一条断点指令（如 x86 的 int3），当 CPU 执行到该地址时触发断点异常，ftrace 接管并执行用户注册的 pre_handler 和 post_handler。
- kprobe： 在函数入口或任意指令前插入。
- kretprobe： 在函数返回点插入，用于捕获返回值。
- jprobe： 已废弃，功能被 kprobe 替代。
# 使用 kprobe 跟踪 do_sys_open 函数入口
echo 'p:my_open do_sys_open $arg1 $arg2' > /sys/kernel/tracing/kprobe_events
echo 1 > /sys/kernel/tracing/events/kprobes/my_open/enable2.4 uprobe：用户态动态探测
uprobe 是 kprobe 在用户空间的对应实现。它通过在用户态程序的指令地址插入断点，实现对用户态函数的动态跟踪。uprobe 不修改目标程序的二进制文件，而是通过内核的 uprobe 模块在运行时注入断点。
- 目标： 任意用户态可执行文件或共享库中的函数。
- 符号解析： 依赖 ELF 文件的符号表（.symtab / .dynsym）。
- 典型场景： 分析应用程序性能瓶颈、调试用户态与内核态交互。
# 跟踪 /usr/bin/redis-server 中的 main 函数
echo 'p:redis_main /usr/bin/redis-server:0x4a5f0' > /sys/kernel/tracing/uprobe_events
echo 1 > /sys/kernel/tracing/events/uprobes/redis_main/enableobjdump -t /usr/bin/redis-server | grep main 或 readelf -s /usr/bin/redis-server 获取函数偏移地址。
2.5 function tracer：全量函数调用跟踪
function tracer 是 ftrace 框架的核心能力之一，它利用编译器在每个内核函数入口插入的 mcount（或 fentry）调用，实现对所有内核函数的跟踪。与 kprobe 不同，function tracer 不需要断点，而是通过修改函数入口处的调用目标来实现动态开关。
- mcount / fentry： 编译器在编译时插入的占位调用，默认指向一个空函数（nop）。
- 动态修改： ftrace 在激活时，将 mcount 调用重定向到 ftrace 核心处理函数。
- 过滤器： 支持按函数名、模块、子系统的粒度进行跟踪，避免全量跟踪带来的性能冲击。
# 跟踪所有以 "tcp_" 开头的内核函数
echo 'tcp_*' > /sys/kernel/tracing/set_ftrace_filter
echo function > /sys/kernel/tracing/current_tracer
echo 1 > /sys/kernel/tracing/tracing_onset_ftrace_filter 缩小跟踪范围。
2.6 四种机制的工作原理对比 SVG 图
下图从插桩位置、触发方式和数据流向三个维度，对比四种核心机制的工作流程：
2.7 核心区别总结
四种机制在插桩时机、作用域和稳定性上存在本质差异，理解这些区别有助于在实际问题中快速选择正确的工具：
- 插桩时机： tracepoint 是编译时静态定义；kprobe/uprobe 是运行时动态插入；function tracer 依赖编译时预留的 mcount 占位，但可在运行时动态开关。
- 作用域： tracepoint 仅覆盖预埋点；kprobe 可覆盖整个内核代码；uprobe 覆盖用户态代码；function tracer 覆盖所有内核函数（受过滤器限制）。
- 稳定性： tracepoint 提供 ABI 保证，跨内核版本兼容性最好；kprobe/uprobe 依赖符号地址，内核升级后可能失效；function tracer 的过滤器接口稳定，但函数名可能变化。
- 性能开销： tracepoint 未激活时开销为零；function tracer 即使未激活也有极小的 mcount 调用开销（现代内核已优化为 nop）；kprobe/uprobe 的断点异常处理开销相对较高。
uprobe_events 中的 $stack 或 $retval 等动态参数，避免硬编码地址。
2.8 实战选型决策树
面对一个具体的跟踪需求，可以按照以下决策路径选择最合适的机制：
- 需要跟踪内核预埋事件（如系统调用、调度切换）？ → 使用 tracepoint。
- 需要跟踪内核中任意函数，且该函数没有 tracepoint？ → 使用 kprobe。
- 需要跟踪用户态程序的函数调用？ → 使用 uprobe。
- 需要获取全量内核函数调用图或延迟分布？ → 使用 function tracer。
- 需要同时跟踪内核和用户态的函数调用关系？ → 组合使用 function tracer + uprobe，通过时间戳关联。