跟踪、观测与 eBPF
这页讲的是：系统出了问题，不是只能靠猜。Linux 内核提供了大量跟踪和观测能力，帮助我们看清性能瓶颈、延迟路径、错误来源，以及运行时到底发生了什么。
这块是什么
跟踪与观测，讲的是如何在不盲猜的前提下观察系统。printk、tracepoint、perf、ftrace、eBPF 等工具和机制，帮助我们理解：哪个函数耗时、哪个路径抖动、哪个事件频繁发生、哪个子系统在拖慢整机。
可以把这一块理解成“系统的体检和透视工具箱”：不是替系统干活，而是帮你看清系统正在怎么干活。
它负责什么
记录系统发生了什么
- 打印日志
- 记录事件
- 观察路径上的关键节点
- 让问题不再只靠主观猜测
分析性能和延迟
- 找出热点路径
- 定位等待时间
- 识别抖动来源
- 帮助理解吞吐和延迟的真实瓶颈
按需扩展运行时观测
- 使用 tracepoint、perf、eBPF 等机制
- 在不改主逻辑的情况下观察系统
- 更灵活地采集运行信息
- 让“观测能力”本身也具备可编程性
为什么观测很难但又必须做
| 挑战 | 你现在怎么理解 | 为什么必须重视 |
|---|
| 系统很复杂 | 一个问题可能跨调度、内存、网络、驱动多个模块。 | 不观测，你很容易只盯住症状而看不到真正路径。 |
| 问题常常是动态的 | 很多性能抖动或偶发故障只在运行中出现。 | 静态看代码不一定能还原现场。 |
| 观测本身也要控制代价 | 不是所有观测都能无限细，过重的观测会反过来影响系统。 | 好的观测要在信息量和扰动成本之间平衡。 |
| 需要跨层理解 | 光看日志、光看 CPU、光看某个函数都可能不够。 | 你需要把多个模块的迹象串起来解释。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| printk | 最基础的内核日志输出方式，适合看系统显式报告了什么。 |
| tracepoint | 内核预留的观测点，方便在关键位置采集事件。 |
| perf | 常用于性能分析、热点定位和采样观察的工具链。 |
| ftrace | 用于观察函数调用和执行路径的内核跟踪能力。 |
| eBPF | 让你在较受控的前提下给系统增加运行时观测和处理逻辑的机制。 |
为什么重要
- 没有观测能力，很多内核问题都只能靠猜，效率极低。
- 跟踪工具让你把“感觉慢”“偶尔卡”“好像有丢包”变成更具体的证据链。
- eBPF 让现代 Linux 在运行时观测和网络/安全扩展方面更灵活。
- 学会这一块，你会更容易把前面学过的模块知识用于真实排错和理解系统行为。
常见误解
- 误解一：观测就是看日志。实际上日志只是最基础的一层，很多问题还需要事件、采样和路径级跟踪。
- 误解二：eBPF 只是网络技术。实际上它已被广泛用于性能分析、观测和安全场景。
- 误解三：观测是进阶工具，入门不用管。实际上只要你想真正理解系统运行过程，迟早会依赖它。
它不负责什么
- 它不替代调度、内存、网络等核心子系统，只是帮助你观察这些子系统。
- 它不保证自动给出答案，仍然需要你理解系统路径并解释数据。
- 它不等于单一工具，而是一整套能力和方法。
和其他模块的关系
| 相关模块 | 关系 |
|---|
| 调度器 | 很多性能与延迟问题需要观察任务切换和 CPU 时间分配。 |
| 内存管理 | 卡顿、回收、OOM 等问题往往必须通过观测来定位真实压力路径。 |
| 网络 | 丢包、抖动、延迟异常常需要事件级和路径级跟踪。 |
| 安全 / eBPF | eBPF 把观测能力和某些运行时扩展能力连接起来。 |
你现在可以先把观测手段按粗细分层
| 观测层次 | 更像在回答什么问题 | 什么时候最先想到它 |
|---|
| 日志 | 系统明确报告了什么事件和状态。 | 当你先想知道“发生了没有”时。 |
| 事件点与路径跟踪 | 某条关键路径到底经过了哪些节点。 | 当你知道有问题，但还不知道路上卡在哪时。 |
| 性能采样 | CPU 时间、热点函数和等待时间主要花在何处。 | 当你感觉“慢”，却还不知道慢在谁身上时。 |
| 可编程观测 | 怎样在运行期按需采集更贴近当前问题的现场信息。 | 当现成日志和固定观测点不够用时，eBPF 这类能力就开始显得特别有价值。 |
读完这页后，你应该能回答
- 为什么理解系统运行时行为离不开跟踪和观测？
- 日志、tracepoint、perf、ftrace、eBPF 大致各处在什么层次？
- 为什么观测本身也需要控制成本和方法？
后面适合继续问：eBPF 和传统跟踪工具各自擅长什么？为什么同一个问题常常要结合多个观测角度？观测结果应该怎样反过来帮助理解调度、内存和网络？