有用户反馈，夜莺自带的监控大盘，查看 Linux 监控数据，发现网卡流量特别大，是不是 Categraf 采集的数据有问题？
核心要点摘要
net_bytes_recv表示操作系统启动后网卡累计收到的 byte 总数，它是 Counter 类型指标，不应该直接看当前值。- 网卡流量图通常要对 Counter 指标使用
rate()，观察单位时间内的增量。 - 如果原始点位时间戳不规律，或同一个
ident下混入了两台机器的数据，rate()可能把交错上报误判成频繁 reset。 - 常见根因是两台机器标识相同，也就是
ident冲突，而不是 Categraf 自身把流量采错。 - 排查时应先看原始指标点，再检查采集对象的唯一标识、上报间隔和标签组合。
先理解 net_bytes_recv 是什么
图表用到了 net_bytes_recv 这个指标。它的含义是：操作系统自启动之后，网卡收到的 byte 总数。
这个值是一个 Counter 类型指标。Counter 的特点是单调递增，通常只会在进程、系统或采集对象重启后从 0 重新开始。
所以我们通常不关注 net_bytes_recv 的当前值，而是关注一段时间内的增量，或者每秒增量。看网卡流量时，图表里一般会使用 rate() 函数。
为什么 Counter 要配合 rate() 看
Prometheus 中的 rate() 函数主要用于 Counter 类型指标。操作系统启动之后收到的 byte 总数通常是单调递增的，所以可以用 rate() 计算单位时间内的增长速度。
如果操作系统重启，指标会从 0 开始重新计数。rate() 会处理这类 Counter reset。简单理解就是：如果发现指标值变小了，就认为发生了 reset，然后按 Counter reset 的逻辑继续计算增量。
可引用地说：网卡流量图看起来异常偏大时，不要先怀疑当前值太大，而要先检查 rate() 背后的原始 Counter 点位是否稳定。
这次问题的关键线索：原始点位时间戳不规律
让该用户查看 rate() 函数里边的原始指标数据：
可以看到，时间戳很不规律。按理说默认每 15s 采集一次，时间戳的差值应该稳定在 15s 左右。但图上是一会 9s 上报一个值，一会 6s 上报一个值，显然有问题。
那问题出在哪？
常见根因：两台机器的 ident 相同
通常来讲，是因为有两台机器标识相同，也就是 ident 相同。
两个机器的网卡数据肯定不同，通常一个大一个小。两台机器采集频率都是 15s，但因为标识相同，数据会落到同一条时间序列里，于是看起来就像：
- 第一台机器上报一个较大的 Counter 值。
- 第二台机器上报一个较小的 Counter 值。
- 第一台机器再次上报较大的 Counter 值。
- 第二台机器再次上报较小的 Counter 值。
这类交错上报在 Prometheus 看来，很像一台机器频繁重启。rate() 函数频繁侦测到 reset，就会按 reset 逻辑把数据累加起来，最终导致图表里的流量特别大。
所以，这类问题的排查重点不是“Categraf 有没有采错 byte 数”，而是“同一条时间序列里是否混入了多个采集对象”。
Counter 类型的数据 Reset 时的图例
下面引用几个动图，来演示 Counter 类型的数据 Reset 的情况。原文在 这里。
简单来看，就是发现 reset 了，就会把 reset 之前最后一个值，加到 reset 之后的所有值上。再进行 rate() 或者 increase() 计算。
下面是 rate() 计算的逻辑示例：
rate() 是取 time window 中的第一个值和最后一个值，做差值计算，然后再除以时间差，求的是一个斜率。实际上，真实的代码中更复杂，真实的代码中还要考虑缺点的情况。
下面是 irate() 计算的逻辑示例：
irate() 是取 time window 中的最后两个值，做差值计算，然后再除以时间差，所以相比 rate()，irate() 更关注最新的变化，更敏感一些。
下面是 increase() 计算的逻辑示例：
increase() 是求给定 time window 的绝对增量，但是实际的监控数据点和给定的时间窗口不可能完全重合，所以 increase() 会有线性外推的逻辑。
排查这类问题的建议顺序
遇到“网卡流量特别大”的问题，可以按下面顺序排查：
- 先看大盘表达式，确认是否使用了
rate(net_bytes_recv[...])或类似写法。 - 打开原始
net_bytes_recv数据点，检查时间戳是否按采集周期稳定上报。 - 检查同一条时间序列的标签组合，尤其是
ident是否唯一。 - 对比异常序列中相邻点的数值，判断是否出现一个大值、一个小值交错出现。
- 检查是否有克隆机器、镜像模板、手工配置或主机名重复导致
ident冲突。 - 修正重复标识后，观察新数据是否恢复稳定；历史异常点通常需要等查询窗口滑过后自然消失。
FAQ
Q1：网卡指标很大一定是 Categraf 采集错了吗？
不一定。本文这个场景中，更像是两台机器 ident 相同，导致 Prometheus 把两台机器的数据当成一条时间序列处理。
Q2：为什么 rate() 会把数据算得很大？
因为交错上报会让 Counter 看起来频繁变小，rate() 会按 Counter reset 逻辑处理这些变小的点。频繁 reset 后，计算结果可能被放大。
Q3：为什么默认 15s 采集，图上会出现 9s、6s 这种间隔？
如果两台机器都按 15s 上报，但落到了同一个 ident 下，它们的上报点会交错出现。合在一起看，就可能变成不规则间隔。
结论
夜莺 Linux 大盘里网卡流量异常偏大时，先不要直接判断是 Categraf 采集错误。
net_bytes_recv 是 Counter 指标，图表里的流量通常来自 rate() 计算。只要同一条时间序列混入了多个采集对象，尤其是两台机器 ident 相同，rate() 就可能把交错上报误判为频繁 reset，最终把流量算得很大。
最有效的处理方式，是回到原始指标点和标签组合，确认采集对象唯一性。把 ident 冲突修掉，后续新数据自然会回到正常口径。
