操作系统内功 · 第 50 篇｜ftrace 与内核追踪：tracefs、静态插桩与 function tracer

内核观测的两条插桩路线

第 9 篇讲过 eBPF 的演进全景，第 34 篇给过观测工具箱；这一篇回到它们的共同地基——内核自身的插桩设施。内核可观测性建立在两条互补的路线上。静态插桩：开发者把观测点直接埋进内核源码，形如成百上千个具名的 tracepoint，覆盖调度、内存、文件系统、网络各子系统；它们在未启用时被补丁成几乎零开销的空操作，启用后才真正采集数据，字段与语义随内核版本稳定演进，是长期监控与告警的首选。动态插桩：不修改代码、不重新编译，现场把任意内核函数的入口改造成探针，按需附加、按需移除，适合临时取证与下钻未知路径。

ftrace 正是这两条路线的原生集成地：它既是动态插桩的实现者（function tracer 通过编译期埋下的调用钩子现场启用），也是 tracepoint 事件的集散地（tracefs 的 events 目录下集中管理与过滤）。更妙的是，ftrace 的这两套设施同时是外部框架的挂载点——perf 的内核侧采样、BPF 程序的 attach 目标（kprobe 与 tracepoint），底层都是同一套插桩设施。理解 ftrace，等于拿到了整个内核观测生态的公共接口。

一个成本视角先立住：function tracer 启用后的开销在每次函数调用的纳秒级，tracepoint 在每事件几纳秒级，两者都远低于一次系统调用；关掉后近乎零负担。这意味着 ftrace 可以在生产环境短时开启，这是它与「打日志、加打印、重编内核」这类重型手段的根本区别，也是内核开发者坚持把观测内建的原因。

ftrace 的历史也值得一提：它诞生于内核开发者自己的追踪需求，早期作为实时特性补丁集的一部分，后来整体进入主线，成为今天所有内核观测工具的地基。这段身世解释了它的气质——为开发者取证而生，接口朴素、直来直去，没有报表没有界面，一切以最快拿到调用事实为目标。用惯了面板化监控的工程师初次接触会觉得简陋，但正是这种朴素让它无处不在：任何一台 Linux 机器，无需安装任何东西，就能立刻开始内核级取证。灾备机器、客户环境、安全隔离区，ftrace 是唯一保证在场的那一个。

两条路线的选择哲学还可以从成本曲线理解：静态插桩是「预付」——内核体积换随时可用的稳定观测点；动态插桩是「现付」——按需启用、随用随拆，但没有稳定性承诺。成熟平台的组合是静态为主、动态为辅：核心指标全部锚定 tracepoint，动态探针只用于突发事件取证。这个组合的韧性在于：核心观测不随内核小版本漂移，应急能力又不失灵活性。

tracefs：一切从文件开始

ftrace 的用户接口是 tracefs 文件系统，现代发行版挂载在 /sys/kernel/tracing（更老的内核藏在 debugfs 之下）。打开这个目录，最重要的一批文件如下。current_tracer 选择当前激活的追踪器，available_tracers 列出内核编译支持的追踪器清单；trace 是环形缓冲区的人工读取口，trace_pipe 是实时流式出口（读走即消费）；buffer_size_kb 调缓冲大小，多核机器上按 CPU 独立缓冲。set_ftrace_filter 与 set_ftrace_notrace 分别是函数白名单与黑名单，available_filter_functions 列出所有可以被动态插桩的函数——这张清单本身就是内核函数面的地图。

events 目录是静态 tracepoint 的集散地：按子系统分目录（sched、irq、net、memory 等），每个事件目录下有 enable 开关、format 字段说明与 filter 过滤器。kprobe_events 与 uprobe_events 是动态探针的登记处，前者在内核函数上设点，后者在用户态二进制的符号上设点。instances 目录支持创建多个追踪实例，各自独立的缓冲与配置，可以同时跑「长时低开销的 tracepoint 监控」与「短时 function_graph 取证」互不干扰。

生产环境的常备操作是过滤与限流。直接对所有函数开 function tracer 会产生海量事件冲垮缓冲，正确姿势是先在 set_ftrace_filter 里写入目标函数名（支持通配），把追踪面收窄到个位数函数；缓冲大小按「最坏情况下你要保留几秒的事件」估算，追不到想要的现场往往只是缓冲太小被冲掉。读数据时优先 trace_pipe 实时流，trace 文件读的是缓冲快照，取证场景两者搭配使用。

再补几个提升效率的文件。按 CPU 划分的缓冲目录可以逐核读取，排查「只在某个核上发生的怪事」时特别有用；进程名对照文件记录缓冲里出现过的进程，帮助把事件归属到具体进程；选项开关控制时间戳、调用链附加等行为，其中记录内核栈的选项开启后，每条事件都附带完整栈——追「谁触发了这个事件」时是利器，代价是缓冲消耗大增，按需开关。把这些零碎文件组成自己的检查清单，tracefs 上手速度会快一个量级。

function tracer 与 function_graph

function tracer 的用法三步走：echo function 写入 current_tracer，echo 目标函数写入 set_ftrace_filter，然后 cat trace_pipe 观察流。输出每行记录哪个 CPU、哪个进程上下文、在什么时刻调用了哪个函数。它的价值是回答「谁在调用这个函数、调用频率多高、来自哪条路径」——比如怀疑某内核函数被高频触发造成 CPU 抬升，function tracer 五分钟就能锁定调用方。

function_graph 是它的进化版：不只记录入口，还记录返回，按缩进还原调用树，并给每个函数标注耗时——短调用安静掠过，慢调用带着醒目的加号与微秒数跳出。用 set_graph_function 指定入口函数后，能看到这个函数内部完整的调用层级与各层耗时分布，相当于内核函数级的火焰图剖面。排查「一个系统调用为什么慢」，function_graph 是最直接的手术刀：延迟在哪一层、哪一支子调用吃掉了时间，一目了然。

还有几个内置的「最坏路径追踪器」值得点名。irqsoff 追踪系统里关中断最长的窗口——中断被压住多久，外部事件就丢多久，这是延迟毛刺的元凶之一；preemptoff 与 preempt 相关，wakeup 与 wakeup_rt 专门测量任务从被唤醒到真正上 CPU 的调度延迟，实时性调优的看家工具。这些追踪器的共同姿势是：平时关着，怀疑有毛刺时开启，它们会自动把「最坏的那一次」连同完整调用栈留在缓冲头部，专治「P99 偶发尖刺抓不到现场」的顽疾。

举个完整的小例子串起用法：怀疑网络收包路径有延迟毛刺，先用函数级耗时追踪钉住收包入口，观察子调用耗时分布；发现某个驱动函数偶尔耗时异常，再切换到关中断追踪器确认这段时间中断是否被压制；最后打开网络子系统的 tracepoint 事件流，把毛刺时刻的收包、丢包计数拼上时间线。三种视角十分钟内完成一轮取证，全程不重启、无侵入——这就是 ftrace 的工作节奏：快进快出，每一步都留下可复看的缓冲数据。

追踪器的开关与缓冲的管理还要防一个高频事故：忘记关闭。调用级追踪在高频函数上全量开启，几分钟就能写满缓冲并消耗可观 CPU；取证结束忘了关，负载毛刺持续到下一次重启。纪律是脚本化开关（开与关成对出现，脚本退出时无论如何都清理）、缓冲大小按需调整而不是一味加大、以及监控 ftrace 自身的开销。让取证工具本身可观测，是观测工作者的自我修养。

串一个真实感十足的排查故事收尾。线上服务周期性 CPU 抬升，火焰图只显示内核符号占比高却看不出脉络；值班工程师用函数级耗时追踪钉住可疑入口，几分钟抓到一条规律：每次抬升前都有大量页表相关调用，随后定位到某个定时任务在大规模扫描内存——完整调用链条就躺在缓冲里，从发现到定性不到半小时。同样的故事用加日志、加重启的方式排查，通常要以天为单位。这就是 ftrace 的价值密度：不改变系统，却让系统把话说完。

tracepoint 与 kprobe：两条插桩路线的实操

静态 tracepoint 的实操最省心。以调度切换为例：echo 1 写入 events/sched/sched_switch/enable 即开始采集；cat 打开 format 文件能看到每个字段的类型与偏移；过滤器直接 echo 条件表达式写入 filter 文件，比如只记录某个进程名的切换事件。tracepoint 的字段语义由内核开发者维护，跨版本相对稳定，适合沉淀成固定的监控脚本与告警规则；perf 也能直接消费这些事件（perf record 配事件名），把 ftrace 的采集面与 perf 的统计面打通。

动态 kprobe 则面向「tracepoint 没覆盖的地方」。向 kprobe_events 写入一行定义即可在任意内核函数入口设点，写法上能直接引用函数参数、寄存器与返回值，返回探针还能挂在函数出口抓返回值。这相当于给内核函数加了临时的 printf——不重编、不重启、随用随删。约束也要知道：探针函数的可用性随内核版本漂移，内联优化的函数设不了点，错误引用参数会导致注册失败，所以动手前先确认目标函数存在于 available_filter_functions，并从小探针开始验证。

两条路线的选择标准简单：长期监控选 tracepoint，语义稳定、生态成熟；临时取证与下钻未知路径选 kprobe 与 function_graph，灵活但没有稳定性承诺。BPF 程序的 attach 目标同样是这两者（第 9 篇的桥梁在此落地），所以今天在 ftrace 里练熟的函数面知识，明天写 BPF 工具时原样复用——观测技能的复利来自这层公共地基。

动态探针也有它的礼仪。生产环境设探针要有审计与命名规范，探针名带上工单号或负责人缩写，用完即删，避免累积成无人认领的定时炸弹；参数引用写错时注册会失败，报错信息往往晦涩，从小探针逐步加参数是低成本试错法。另一个高级玩法是把探针与 tracepoint 的事件流导给 BPF 程序做内核内聚合，只把统计结果送出来——开销进一步压低，这也是现代观测平台的标准架构。工具在演化，插桩点的知识始终是通用货币。

与 perf、BCC、bpftrace 的生态位分工

把四个工具放回一张地图。ftrace：内核自带、零额外依赖，函数级粒度与调用树能力独一无二，适合「内核行为取证」——谁在调用、耗时几何、最坏路径在哪。perf：采样与硬件性能计数器的天下，火焰图、cache miss、指令级剖析靠它，tracepoint 统计也常借道 perf。BCC 与 bpftrace：BPF 时代的表达力王者，内核内聚合（直方图、计数、复杂过滤）与跨事件关联是它们的主场，代价是写脚本的开发成本。四者共用底层插桩设施，技能相互迁移。

实操经验可以浓缩成一套下钻流程：先用 perf 火焰图看面——热点在哪、占比几何；面里有疑问但需要调用链细节时，切 function_graph 下钻函数级耗时；需要跨进程、跨事件的统计关联（比如「每秒哪些进程在刷脏页、每次刷多少页」）时，上 bpftrace 或 BCC 写小工具；tracepoint 级的固定指标则沉淀成常驻监控。这套流程的每一步都有现成工具，不需要重复造轮子，也符合第 34 篇强调的「从面到点」的观测纪律。

最后一条工程提醒：内核观测的所有工具都在消耗被观测系统本身的资源，开高开销追踪器追生产毛刺，可能把毛刺追成故障。纪律是三段式——低开销常驻（tracepoint 统计、采样）、中开销短时（function_graph 取证）、高开销离线复现（完整工具链在压测环境跑），生产环境永远只留在前两段。

团队落地建议分三步。第一步，把 tracefs 的常用操作沉淀成脚本库：一键跟踪函数、一键抓 tracepoint、一键导出调用树耗时榜，降低使用门槛。第二步，把「内核取证」写进值班手册：P99 尖刺、CPU 神秘上涨、IO 延迟抬升三类场景各配一条标准取证流程。第三步，与 eBPF 工具链衔接：ftrace 适合的交给 ftrace，需要长期常驻聚合的迁移到 BPF 工具，两者用同一套函数与 tracepoint 词汇表，知识零重复。观测能力的团队化，靠的就是这种流程化落地。

小结

ftrace 是内核观测的原生地基：tracefs 把追踪器、过滤、缓冲、tracepoint 与动态探针全部组织成文件接口，function tracer 与 function_graph 提供函数级取证能力，irqsoff 与 wakeup 这类最坏路径追踪器专治偶发尖刺。静态 tracepoint 与动态 kprobe 两条插桩路线，同时是 perf 与 BPF 的公共挂载点。

生态位分工记住一句话：perf 看面、ftrace 下钻、BCC 与 bpftrace 做聚合、tracepoint 沉淀常驻监控。工具之间是地基与楼层的关系，函数面知识在四者之间自由迁移。

观测的纪律与工具同样重要：过滤先行、缓冲按需、开销分级，生产只开低与中开销。内核不会再因为「看不清里面发生了什么」而成为排障黑盒——前提是团队把 tracefs 这层接口练成肌肉记忆。