本页目录
先分清自己缺的是哪段证据
第 4 章先把工具从“命令集合”改回“证据来源”。
你现场最常缺的，通常就三种证据：
- 趋势证据：问题是不是整体成立了，范围有多大
- 热点证据：时间主要花在哪，哪类代码或资源最值得继续看
- 路径证据：请求到底走了哪条链，等待和因果关系在哪
证据类型没分清前，工具越重，越容易把现场带偏。
最该怕的不是“工具复杂”，而是观察者效应。Tracing 这类按事件逐条记录的重工具，CPU 和存储开销都很高，严重时不只会拖慢目标，还会把你想测的时间戳本身也测歪。顺序上为什么要先 metrics，不是因为 metrics 更基础，而是因为它几乎不改写现场。
metrics、profiling、tracing 各自回答什么
先记分工，不用先背工具名。
metrics先回答“有没有异常、异常大概在哪、范围有多大”。profiling先回答“时间主要花在哪、谁最热、谁最值得继续看”。tracing先回答“请求怎么走、哪一段在等、因果链怎么接起来”。
这三类东西不是升级版关系，也不是谁更高级。它们回答的是不同问题。
Profiling 自己也不是无害的。原书里有个很实用的细节: 定时采样别偷懒用 100Hz 这种整数频率，99Hz 更稳。否则采样容易和系统里的周期性活动锁步，最后把火焰图采成假热点。
别拿趋势工具回答热点问题，也别拿热点工具回答路径问题
最常见的错法有四种：
- 问题还没缩小，就直接上最重的 tracing
- 只拿到热点图，就开始回答因果问题
- 只看到趋势异常，就开始宣布根因
- 工具已经开始干扰现场了，还把结果当成自然状态
这些错法都在做同一件事：拿一种证据去回答另一种问题。
当前证据只剩异常、解释不了原因时再升级工具
先按这个顺序走：
1. 先用大盘证据确认问题成立
先看延迟、吞吐、错误、资源利用、饱和和变化范围。先确认这是局部症状，还是整体退化。
2. 再用热点证据缩小方向
当你已经知道问题大概落在哪一层，就去看 CPU 热点、调用栈、最慢路径或最重请求类型。
3. 最后才用路径证据压实解释
当你已经知道“最像哪”，但还不知道“为什么会这样”，再进 tracing、事件路径和更重的时序证据。
从上一步走到下一步，条件只有一个：现在这类证据已经解释不动了。
一个最典型的错法：先把最重工具开起来
接口变慢以后，有人第一反应就是“先抓最全的数据”。结果 trace 开了、事件抓了、样本也拿了，会议里还是在争到底是应用、系统、网络还是下游。
问题不在工具不够强，问题在于大家连“现在缺的是趋势、热点还是路径”都没先说清。
更稳的做法是：
- 先用 metrics 确认问题是不是整体成立
- 再用 profiling 看时间主要花在哪
- 最后才用 tracing 去压实因果链
顺序一对，工具反而会变少。
先按趋势、热点和路径选工具
先把问题分到趋势、热点、路径三类
以后拿到一个问题，先问自己：
- 我现在缺的是不是全局趋势证据。
- 我现在缺的是不是热点和时间分布证据。
- 我现在缺的是不是路径和因果证据。
这三件事没分开，就别急着选工具。
热点解释不动时，再换路径证据
出现下面这些情况，就别继续解读同一张热点图了：
- 已经知道哪里热，但不知道为什么热
- 已经知道哪段慢，但不知道它和整体症状怎么接起来
- 已经知道一个异常点，但还排除不了别的方向
这时候该换 tracing 或更细的路径证据。
工具一旦开始扰动现场，就先降级
如果工具本身已经明显带来更高开销、更长延迟或更大噪声，就先回到更轻的证据。先保住问题形状，再谈精细观测。
真要进入 tracing，也别把所有事件源当成同一等级。原生 tracepoint 和 USDT 这类静态点位，代价和稳定性通常都更好；kprobes、uprobes 这类动态探针开销更高，挂在高频路径上时足以把应用再拖慢一截。
证据类型分清以后，很多慢还得回应用侧看
第 4 章解决的是“该拿哪类证据”。第 5 章接着解决“很多慢其实要先回应用侧看”。工具顺序站住以后，后面的应用章才不会被读成泛泛 APM 介绍。