抓包看字节、debug 看流程、流量统计看汇总——三个层次，开销从低到高。 顺序必须是「先统计、再抓包、最后 debug」，因为 debug 可能把设备打死。
上一节讲备份，这一节讲排查用的三件工具。 这一节的核心是「顺序」与「限条件」——技术本身不难。
一、三个工具看三个层次
工具 看什么 开销
抓包 每个包的字节 高 debug 内部控制流程 很高 流量统计 五元组与字节汇总 低（采样）
开销从低到高，所以顺序是「统计 → 抓包 → debug」。 先统计能回答「谁在占带宽」，八成的问题到这一步就有方向了。
二、抓包的内存要算
抓 10000 个包、每包平均 500 字节，加上元数据约 600 字节一个。 1000 个包是 0.6 MB，10000 个是 5.7 MB，100000 个是 57 MB。
十万个包要 57 MB 缓冲，而设备的内存要同时装路由表、缓冲、进程。 所以设备上的抓包必须设「包数上限」与「文件大小上限」——否则会把内存吃掉，然后设备重启，抓到的包也一起丢了。
正确做法：先按「五元组 + 端口」过滤，只抓怀疑的那一小撮流量，再设几百个包的上限。 不加过滤地抓包，等于给设备制造一次故障。
三、流量统计为什么便宜
因为它只记「五元组加字节数」，不记内容。 而且常常是「每 N 个包采样一个」。
采样会不会漏：会。 但排「谁占了带宽」这种问题不需要精确——采样千分之一也够看出「哪个地址占了六成」。
所以两者的分工是清楚的：统计用于找方向，抓包用于看细节。 先用统计锁定「哪条流可疑」，再用抓包看「这条流里的包长什么样」。
四、debug 的唯一正确用法
限时、限条件、限输出量。
限时：三十秒后自动关，而且提前写好关闭命令。限条件：只对某个源地址、某个接口。 限输出量：只输出十条。
无条件开 debug 等于给自己制造一次故障——而且往往是在最忙的设备上、最不该出事的时候。 这一条在 03.07.02 讲日志时也强调过，这里再说一遍，因为它真的会出人命（业务上的）。
五、动手 Demo：抓包、debug、流量统计，三件排查工具的分工
这段列出三个工具的作用层次与开销，再按「每包 500 字节加 100 字节元数据」算三档抓包数量占多少缓冲。
for n in (1000, 10000, 100000):
b = n * 600
P(u" %s 个包：约 %.1f MB。" % (format(n, u","), b / 1048576.0))
实跑输出：
--------------------------------------------------------------------
抓包、debug、流量统计，三件排查工具的分工
--------------------------------------------------------------------
**这三个工具经常被混着用，但它们看的是三个不同的层次。**
工具 看什么 开销 什么时候用
-------------------------------------------------------------------
抓包 每个包的字节 高 协议层问题
debug 内部控制流程 很高 极难复现的问题
流量统计 五元组与字节汇总 低（采样） 谁在占带宽
**「先看流量统计、再抓包、最后才 debug」这个顺序很重要**：因为开销是从低到高，
**而 debug 有可能把设备打死。**
**算一下抓包的内存**：抓 10000 个包，每包平均 500 字节，加上元数据：
1000 个包：约 600,000 字节（0.6 MB）。
10000 个包：约 6,000,000 字节（5.7 MB）。
100000 个包：约 60,000,000 字节（57.2 MB）。
**十万个包要 57 MB 缓冲**——所以设备上的抓包必须设「包数上限」与「文件大小上限」，
**否则会把内存吃掉。**
**NetFlow 这类统计为什么开销低**：因为它**只记「五元组＋字节数」，不记内容**，
而且常常是「每 N 个包采样一个」。
**采样会不会漏**：会。
但**排「谁占了带宽」这种问题不需要精确**——采样 1/1000 也够看出「哪个 IP 占了 60%」。
**所以「统计」用于找方向，「抓包」用于看细节**，两者不冲突。
**debug 的唯一正确用法**：**限时、限条件、限输出量。**比如「只对某个源 IP、只输出 10 条、
30 秒后自动关」。**无条件开 debug 等于给自己制造一次故障。**
「0.6 MB 到 57 MB」这个跨度说明「抓包必须设上限」： 一百倍的量级差，只要不设上限就一定会撞墙。
「采样千分之一也够」这一条要具体化：找「谁占了带宽」只需要相对比例，不需要精确字节数。 而找「为什么这个包被丢了」需要精确——那就得抓包。 工具选择取决于「要相对还是绝对」。
最后一段「无条件开 debug 等于制造故障」是本章的收尾警句： 03.07 这一整节讲的是「管理」，而管理的核心不是「能做什么」，是「知道什么不能随便做」。 这条线从 Console 的唯一性一直贯到 debug 的危险性。
30 秒实验
- 在设备上看一下有没有流量统计（NetFlow／sFlow）功能。
- 试着抓十个包，看命令要不要设上限参数。
- 想一想：debug 开着的时候设备重启了，你怎么知道？
常见误区
- 以为抓包最可靠所以先用。开销高，可能把设备压垮。
- 以为采样统计不准所以没用。找方向不需要精确。
- 以为 debug 能一直开着。必须限时限条件限输出。
自测三问（点开对答案）
1. 三个排查工具的正确使用顺序是什么？ —— 先流量统计、再抓包、最后 debug，按开销从低到高。 2. 为什么设备上抓包必须设包数上限？ —— 十万个包就要几十 MB 缓冲，不设上限会吃掉内存导致重启。 3. 流量统计为什么开销低？ —— 只记五元组与字节数、不记内容，且常做采样。下一节：管理讲完，下一节把路由器拆开看硬件。
- ☐ （本节完，下一节 03.08.01 路由器的构成要素）