扩展 ytti 的评论。

如果我没看错，您的轮询间隔似乎很小，每 10 秒一次。有几个原因可以得到这个结果。

设备端：

• 计数器的错误选择，如果您使用 32 位计数器，如果您以线速运行 10g 接口，它们可能每约 3.4 秒滚动一次
• 计数器更新，许多较大的设备每分钟只更新两到三次计数器，并且永远不能依赖它们同步。每 30 秒低到我会费心进行轮询，即使那样，在触发任何警报或采取行动之前，我总是希望至少获得两分
• 可能会有一个问题，因为发送给 CPU 处理的数据包（也许是网络流）可能会立即被计算，而那些不会被 RE 批处理的数据包（在瞻博网络 MX 上已经看到了这一点）

轮询端：

• 轮询器是否按间隔准确轮询，如果不是，则将其结果与实际轮询时间（例如，yz 秒中的 x 位）一起注入，以便可以计算出合理的速率
• 当计数器重置或 SNMP GET 没有响应时会发生什么，不同的工具以不同的方式响应这些

您的问题是，您的路由器采样和您自己的轮询不会同时发生。也就是说，即使轮询间隔是静态的，轮询间隔包含不同数量的样本，您的数学没有考虑到这些。
假设您已经轮询了 t1,t2,t3，但路由器没有在 t1,t2 间隔采样任何内容，因此 t1,t3 之间的所有流量都以 t2,t3 轮询值结束。导致您的费率在 t1,t2 时为 0，在 t2,t3 时超过线性

现在我将建议一种解决方案，但请与对数学有粗略理解的人进行验证。

首先找出您感兴趣的接口（如果是 ge-1/1/1）：

snmpbulkwalk SWITCH ifDescr|grep ge-1/1/1

然后你会看到它的 ifIndex 数字，假设它是“42”。

然后执行以下操作：

while true; do
  snmpbulkwalk SWITCH ifHCInOctets.42 >> DATA
  date >> DATA
  sleep 1
done

现在分析结果以确定计数器实际更新的平均频率。（如果需要，我可以为分析生成脚本）

然后是我们需要数学的部分，但我会建议一个简单的解决方案。

如果您的更新间隔是 10 秒，则每 5 秒轮询一次，即更新频率的两倍。那么你的样本将是

t0、t5、t10、t15、t20、t25、t30

现在这将是您的原始数据，您不会使用它，但您宁愿像这样从中恢复实际样本

s1 = (t0+t5+t10)/3
s2 = (t10+t15+t20)/3
s3 = (t20+t25+t30)/3

这里的基本原理是，我们希望通过边界进行泄漏，以减少交换机上不准确的轮询间隔的影响。

然后您将绘制 s1、s2、s3，并且您应该获得比现在看到的更平滑/准确的结果。

但是，我确定这不是新问题，并且我确定有正式的解决方案如何恢复最佳准确度，不幸的是，生成该解决方案超出了我的技能范围。一些 math.stackexchange 人会更有能力解决。

由于您以与计数器更新相同的速率进行轮询，因此您可能不同步。

通过配置

snmp-server hc poll <<hundredths of a second>>

您可以将 SNMP 计数器更新的间隔减少到 1 秒之类的时间。当您每 10 秒轮询一次时，这应该会产生更准确的吞吐量值。

仅供参考，这是一个隐藏的命令。