本页目录
先确认问题已经落到内核路径里
第 14 章先给 Ftrace 划边界。它不是默认工具，也不是 perf 的升级版。
Ftrace 最值钱的时候，是你已经知道问题大概率在内核路径里，但还缺下面这类证据：
- 执行顺序
- 路径展开
- 某段内核行为到底什么时候发生
如果问题还没缩到这一步，先别急着进 Ftrace。
Ftrace 还有一个经常被低估的价值：它是受限环境里的零依赖底牌。在没有 perf、没有编译器、也没有 BPF 依赖的极简容器或生产裸机里，只要 /sys/kernel/tracing 还在，你就还能靠最朴素的 echo 和 cat 直接把内核路径撕开。
Ftrace 最适合回答什么
下面这些问题，更像 Ftrace 的地盘：
- 某条内核路径到底怎么走
- 某个内核事件先后顺序是什么
- 某段时间里内核到底在做什么
- 某个假设里的关键内核行为有没有真的发生
这些问题里，Ftrace 的时序感和路径感很有价值。
别先抓一大堆事件，再回头想自己要验证什么
最常见的错法有四种：
- 把 Ftrace 当成“更高级的 perf”
- 问题没定义清楚，就直接大面积开 trace
- 没有明确假设，就先抓一堆内核事件
- 已经拿到答案雏形了，还继续无穷下钻
这些错法都在把 tracing 变成数据收藏。
什么时候值得上 Ftrace
一般要同时满足这几件事：
- 你已经知道问题大概率落在内核
- 你知道自己缺的是路径或时序证据
- perf 或普通指标已经解释不动
- 你能说清这次 trace 是为了验证哪个假设
这四件事站住了，Ftrace 才值得上。
一个最典型的错法：先抓很多，再慢慢想自己到底要看什么
现场里一进入 Ftrace，最容易出现的就是“先抓再说”。
结果往往是：
- 事件抓了很多
- 数据看起来很丰富
- 但没人能说清哪一段才是关键转折
更稳的做法是先把假设说清，再决定挂哪些点、看哪些顺序、验证哪一段路径。
先把假设、路径和事件对上
先把这次 trace 要验证的假设写出来
以后上 Ftrace 前，先写一句话：
我这次要验证的是哪段内核路径在什么条件下发生了什么。
这句话写不出来，就先别上。
路径证据一够用，就及时停手
一旦已经拿到足够解释链的路径和时序证据，就别继续扩大采集范围。Ftrace 最容易过度展开。
真要开函数跟踪，也别一上来就全量放开。更稳的顺序是先用剖析器摸底调用频率，只有当目标函数属于每秒一千次以下的低频调用时，再开精细路径追踪；否则你不是在抓答案，而是在主动制造开销。
Ftrace 和 perf 分工写清楚
以后团队里至少把这条写清：
- perf 更像热点和栈
- Ftrace 更像路径和时序
别再把两者当成“轻重升级关系”。
固定事件不够时，再上更灵活的观测
第 14 章解决的是“内核路径 tracing 什么时候值得上”。第 15 章接着解决“当标准事件还不够时，BPF 该怎么把问题变成可观测问句”。