网络流量实时速率是如何计算的?

首先我们要知道网络流量实时带宽是如何计算出来的,我们先拿接口流入流量来举例子。
通过SNMP的ifInOctets键值,我们可以获取到接口流入数据量的累计总量。那么如果我们想要计算流入流量的带宽速率,只需要固定一个时间间隔(比如30s),在前后分别获取一次累计总量,再计算差值,即可得出30s的流入数据量总量。这时候就是一个简单的速度计算了,数据总量差值/时间间隔,就是这段时间内的流入流量的平均带宽速率。这也和瞬时速率同理,只要时间间隔越短,越能代表瞬时速率。
那么我们就可以获得计算公式:

In端口速率
Out端口速率

为什么要用Counter64来获取网络流量数据?

首先讲讲Counter32的问题在哪里吧。
上文我们提到,计算网络流量速率是通过获取累计总量的差值来计算的。于是就有一个很明显的问题:这是一个累计值,只要设备在使用就会导致这个值无限的累加,而计算机处理数据是有最大位长限制的。那如果达到该怎么办呢?就会将这个值清零再重新进行累加。这样就有一个最大值,达到最大值时就会清零重新进行计算。
而Counter32呢,这个最大值为(2^32-1)Byte,也就是超过4GB时就会进行清零。
当我们端口速率过大的时候,这个最大值显然是不够用了。当累计值被清零,而计算程序不知道时,就会导致计算速率不准确、异常。举个例子:
假设我们的业务量端口速率有2Gbps,也就是250MB/s,在16s左右时,累计值就会被清零。如果速率计算程序的时间间隔大于16s,则会造成数据计算异常。
诚然,将时间间隔修改成16s内,甚至10s,或许可以解决问题。但终究是治标不治本的方案。而且时间间隔这么短也会加大网络的开销,因为要频繁通过SNMP获取信息。假如端口的数量一多,更是会造成其他的开销增大。
我拿我的业务举例子,当时间间隔设置为30s的时候,流量速率显然是异常的。而设置为10s,则是正常的(其实也不完全正常)。

栗子

问题在哪不言而喻:Counter32的最大值太小,不够用。
而Counter64则是用于解决这个问题的。Counter64的最大值为(2^64-1)Byte,也就是16EB。就算是千兆口24小时跑满,也需要4000多年才能跑完。以目前的发展情况来看,16EB是完全足够用的,不需要担心。
所以只要将Counter32更换为Counter64就能解决问题。

如何更换Counter64来获取网络流量数据?

在SNMP中,更换到Counter64,键值以及OID也会发生变化:
流入流量:

* Counter32 Counter64
键值 ifInOctets ifHCInOctets
OID 1.3.6.1.2.1.2.2.1.10 1.3.6.1.2.1.31.1.1.1.6

流出流量:

* Counter32 Counter64
键值 ifOutOctets ifHCOutOctets
OID 1.3.6.1.2.1.2.2.1.16 1.3.6.1.2.1.31.1.1.1.10

计算公式也可以换一下了~

In端口速率
Out端口速率