课程（6 节，按顺序学）

① 先分清两种完全不同的东西：聚合与采样

入门 · 约 8 分钟

本课目标：搞清 NetFlow/IPFIX 和 sFlow 不是「版本不同」，而是两种根本不同的哲学——以及为什么这决定了它们各自能回答什么问题。

为什么需要它

接口计数器只能告诉你「这个口跑了 800Mbps」。它回答不了：

· 这 800M 是谁在用？
· 去哪儿了？
· 什么时候开始的？

★ 流量可观测性要补的就是这个洞：把「多少」变成「谁、去哪、多久」。

★★★ 聚合派：NetFlow / IPFIX

设备在自己内部维护一个流缓存，按五元组把包聚合成流：同一个五元组的包不断累加包数和字节数，最后导出一条统计记录。

★ 好处：统计精确（未采样时就是真值）、数据量小。
★★ 代价：要等流结束（或超时）才导出 → 天然滞后；而且记录不自解释，收集器要靠模板才能读。

★★★ 采样派：sFlow

完全不聚合。按固定比例（比如 1:1000）抽出整个包的包头，原样送走，另外周期上报接口计数器。

★ 好处：设备开销极低且恒定、能看到包级细节（TCP flags、真实包长分布）、零滞后（采到就送，没有缓存）。
★★ 代价：所有流量数字都是估算（采样数 × 采样率）。

所以「哪个更好」是个错问题

★★★ 它们回答的问题不同：

· 要精确计费/审计 → 聚合派，而且不能采样
· 要秒级看到突发 → 采样派（没有 timeout 滞后）
· 要包级细节（谁在发畸形包）→ 只有 sFlow 给得了

★ 现网常见做法是两个都上，各管一段。

实验重点

• ★★★ NetFlow/IPFIX = 在设备上聚合成流；sFlow = 抽包头原样送走。这是两种哲学，不是版本差异。
• ★★ 聚合派统计精确但滞后一个 timeout；采样派零滞后但数字全是估算。
• ★ IPFIX 是 NetFlow v9 的标准化版本，新建网络直接上 IPFIX。

② ★★★ 「1:1000 采样」到底意味着什么

入门 · 约 10 分钟

本课目标：把采样率的真实代价算清楚——它不是「精度损失千分之一」，而是大流全留、小流全扔的一次极端筛选。

先看一个反直觉的数字

一条 P 个包的流，至少被采到一次的概率是：

P(看得见) = 1 - (1 - 1/N)^P

★ N=1000 时代进去：
· 10 个包的流 → 约 1%
· 100 个包 → 约 10%
· 一万个包 → 约 99.99%
· 一百万个包 → 实际就是 100%

★★★ 所以 1:1000 的真实含义不是「精度千分之一」。

它是一次按大小做的筛选

★★★ 大流怎么采都跑不掉，小流基本必然消失。这个筛选是极端的，而且是隐形的——报表上不会写「这里少了 3000 条流」。

★ 于是你会得到一份看起来很正常的数据：字节总量几乎准确（因为字节几乎全由大流贡献），没人会怀疑它。

★★ 但连接数已经错得面目全非

★★★ 「量对、条数不对」是采样数据最典型的失真形状：

· 总字节 → 误差可能只有个位数百分比 ✓
· 连接数 / 独立源 IP 数 / 独立目的数 → 可能低一个数量级 ✗

★ 所以任何基于「计数」的分析（有多少个客户端、多少次连接尝试）在采样数据上都是不可信的。

实验重点

• ★★★ P(看得见) = 1 - (1-1/N)^P。1:1000 下 10 个包的流只有 1% 概率出现。
• ★★ 采样不是均匀损失精度，是大流全留、小流全扔——而且这个筛选是隐形的。
• ★ 字节总量准 ≠ 数据可信：基于「计数」的分析在采样数据上会低一个数量级。

③ ★★★ 为什么采样数据查不出端口扫描

进阶 · 约 10 分钟

本课目标：这一课的结论比「看不见」更微妙：你确实看到了东西，但看到的那部分不再像扫描。

扫描长什么样

一次端口扫描的形状是：一个源、极多目标、每个目标极少包。

比如打 10000 个目标，每个目标 2 个包（SYN + RST）。

★ 注意它和「老鼠流」在单条记录上长得一样，区别只在聚合起来的形状。

算一下能看到多少

1:1000 采样下，2 个包的流被看见的概率是 0.2%。

★ 于是 10000 个目标里，大约有 20 个出现在你的数据里。

★★★ 而「至少看到一个」的概率是 ≈100% —— 这个数字非常容易让人得出错误的安慰：「你看，数据里有它」。

★★★ 被破坏的是形状，不是完整性

关键在这里：那 20 条记录指向 20 个互不相关的目标，看起来就是 20 次普通的、失败的连接尝试——和背景噪声无法区分。

★★★ 检测扫描靠的是密度（一个源短时间打了上万个目标），而采样恰好把密度打下来了。

★ 所以这不是「告警阈值调低一点」能解决的：证据的形状已经没了。

这解释了一场常见的争论

★★ 同一份采样数据，两个团队结论相反，而双方都没错：

· 网络团队问「谁占带宽」→ 答案在大流里 → 采样完全够用
· 安全团队问「有没有人扫我」→ 答案在小流里 → 采样删掉了全部证据

★★★ 所以正确的结论不是「采样率调到多少合适」，而是两类需求需要两套采集策略。

实验重点

• ★★★ 采样不是让扫描「看不见」，而是让它「不再像扫描」——破坏的是形状，不是完整性。
• ★★ 「至少采到一条」是毫无用处的保证：检测靠密度，而采样打掉了密度。
• ★ 边界/关键区域要全量采集，骨干上才采样——这不是调参问题，是策略问题。

④ ★★ 你的「实时流量大图」其实是滞后的

进阶 · 约 8 分钟

本课目标：搞清流缓存和两个 timeout 怎么决定「数据什么时候才出现」，以及为什么突发流量的告警天然延迟。

流缓存里发生了什么

聚合型采集把包累加进流缓存，什么时候导出由两个超时决定：

· 活跃超时（常见 60s / 1800s）：流还在继续也要切一刀导出
· 静默超时（常见 15s）：流安静这么久就认为结束

★ 还有一个优化：看到 TCP 的 FIN/RST 就立刻导出，不用干等静默超时。

★★★ 于是「现在」永远看不到

一条正在进行的下载，跑了 20 秒，活跃超时 60 秒——它此刻完全不在你的报表里，还要等 40 秒。

★★★ 所以你看到的永远是「已经导出的那部分历史」，而不是当下。这不是实现缺陷，是这个机制的固有性质。

★★ 一个容易踩的统计错误

活跃超时会把长流切成一串记录。所以一次 1 小时的下载在报表里可能是 60 条记录，而不是 1 条。

★★★ 如果你的分析按「记录条数」统计连接数，就会把这一次下载数成 60 次连接。

★ 正确做法是按五元组去重，而不是数记录。

想要秒级怎么办

★ 两条路：

· 把活跃超时调小（代价是记录条数暴增，收集器和带宽都要扛）
· 用 sFlow——它没有流缓存，采到就送，滞后≈0

★★ 这就是为什么很多网络两个都部署：IPFIX 做精确统计，sFlow 做快速感知。

实验重点

• ★★★ 聚合型采集必须等缓存过期才导出，所以「实时大图」滞后一个活跃超时。
• ★★ 活跃超时把长流切成一串记录——按记录数统计连接数会错得很厉害。
• ★ 要秒级可见只能调小超时（代价大）或改用 sFlow（没有缓存就没有滞后）。

⑤ ★★★ 设备一切正常，可界面一片空白

排障 · 约 10 分钟

本课目标：亲手复现本模块最经典的一个静默故障，并理解它教的那个更一般的道理：「我发出去了」和「对方看得懂」是两件事。

先看症状

★★★ 这个故障的形状非常有欺骗性：

· 设备上 show 一切正常
· 导出计数器在涨
· 网络上抓包，UDP 报文确实在飞
· 但收集器界面一片空白

★ 于是人会反复去查设备和网络——那里什么都查不出来。

★★★ 原因：数据记录不自解释

NetFlow v9 / IPFIX 的数据记录里没有字段说明，只有一串二进制值。怎么解析全靠设备之前发过的模板。

★★ 而模板缓存在收集器的内存里。进程一重启就没了。

★★★ 设备并不知道这件事——它只会按固定周期（默认常见 10 分钟）重发一次模板。这 10 分钟里，收到的每一条数据记录只能整包丢掉。

怎么修、怎么防

★ 立刻恢复：去设备上手工触发一次模板重发。

★★ 长期预防：
· 把模板重发周期调短（代价只是一点带宽）
· 收集器重启后主动去触发重发，而不是干等
· 监控收集器的「解析失败计数」，而不只是「接收计数」

★★★ 最后那条是关键：只看「收到多少」永远发现不了这个故障。

更一般的那个道理

★★★ 这个故障值得记住，是因为它的形状在别处反复出现：

「我发出去了」不等于「对方看得懂」。

★ 所以监控一条数据链路时，光看发送端的计数器是不够的——必须看接收端成功处理了多少。这两个数之间的差，才是真正的问题所在。

实验重点

• ★★★ v9/IPFIX 的数据记录靠模板才能解析，模板在收集器内存里，一重启就没了。
• ★★ 症状极具欺骗性：设备侧每个计数器都正常，而收集器把收到的全丢掉。
• ★ 要监控「解析成功数」而不只是「接收数」——否则这个故障永远发现不了。

⑥ 「数据不对」的五种原因，怎么分辨

排障 · 约 10 分钟

本课目标：把整条链路上五个会吃掉数据的地方摊开，并学会用三个计数器快速定位到底卡在哪一步。

五个地方，一样的症状

从真实流量到报表，中间有五处会让数据消失，而它们在界面上长得一模一样：

① 压根没被采样到 → 数据从来不存在
② 还压在流缓存里 → 数据存在，只是还没到
③ 缓存被打满挤掉 → 系统性丢小流
④ 导出报文路上丢了 → 产生了但没送到
⑤ 到了但缺模板 → 送到了却看不懂

★★★ 先分清「丢了」还是「还没到」

★★★ 这是最重要的一次分岔，因为处理方式完全相反：

· 还没到（②）→ 等一个 timeout 就出现了，什么都不用做
· 丢了（①③④⑤）→ 等一万年也不会来

★ 判断方法：等一个活跃超时再看一眼。还是没有，就是丢了。

★★ 三个计数器定位法

★★ 不要猜，比对这三个数：

· 设备的导出计数器 —— 设备发了多少
· 收集器的接收计数器 —— 收到多少
· 收集器的解析成功计数器 —— 读懂多少

★★★ 差在哪一段，问题就在哪一段：
· 设备计数就很低 → 采样太稀 或 没开采集
· 发了但没收到 → 网络丢包（④）或收集器扛不住
· 收到但没解析 → 缺模板（⑤）

最后一句忠告

★★★ 「数据不对」时最常见的错误动作是先去调采样率。

★ 五种原因里只有一种（①）和采样率有关。先定位、再动手，否则调完发现没变化，反而更困惑。

实验重点

• ★★★ 从真实到报表有五处会吃掉数据：采样、流缓存、缓存溢出、导出丢包、缺模板。
• ★★★ 先分清「丢了」和「还没到」——前者等也没用，后者什么都不用做。
• ★★ 用三个计数器（设备导出 / 收集器接收 / 解析成功）定位，不要猜。