我可以使用SNMP工具来绘制设备接口，像Cacti这样的平台甚至可以制作漂亮的graphics，但这些都是基于轮询间隔（通常是每5分钟一次）。
我可以使用CLI;
r1>show int gi0/0 GigabitEthernet0/0 is up, line protocol is up Hardware is BCM1250 Internal MAC, address is 0011.2233.4455 (bia 0011.2233.4455) Description: link 1 MTU 1540 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 35/255, rxload 20/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full Duplex, 1000Mbps, media type is RJ45 output flow-control is XON, input flow-control is XON ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 0/75/3208/72484 (size/max/drops/flushes); Total output drops: 1373910311 Queueing strategy: Class-based queueing Output queue: 0/1000/12 (size/max total/drops) 5 minute input rate 79658000 bits/sec, 19312 packets/sec 5 minute output rate 140174000 bits/sec, 21984 packets/sec 从5分钟的输出速率中我可以看到，我传输的是140Mbps的stream量，但是在过去的五分钟里这个数字是平均值。 所以不是现在，也不比Cacti等更好。
我可以input接口命令load-interval 30 ，将采样率降低到30秒，此时txload和rxload值会变得更加准确。
同样，如果我需要知道哪个链路现在是最大的，我很难相信Cisco路由器和交换机可以做的所有惊人的事情，但他们不能告诉我接口的当前TX / RX速率， 马上。
我明白一个抽样时间可能需要这样一个数字才能达到，那么1秒出了什么问题呢？ CPU的需求肯定不是很多，只需要计算每秒通过的数据包的数量和大小呢？
有人可能已经开发出了自己的工作方式吗？ 我看到其他人也被同样的难题所困扰？
更新 ：我应该给这个更好的背景，所以我现在就试着去做。
我现在对接口吞吐量的一个典型需求就是当一个拥有100Mbps端口的客户响起来，并说：“嗨，我从镜像服务器下载X，但是它只能以20Mbps传输”。 我希望现在能够看到他们的开关jar吞吐量，同时他们正在给我打电话，以证实这一点（非技术客户经常报告我的经验中的错误值）。
所以，在这种情况下，我可以确认客户端口是否已经达到100Mbps，所以他们只能得到20Mbps，因为他们的端口是有容量的，或者甚至是以他们声称的速度（无论是高于还是低于） 。 另外，接下来我要查看为所有这些客户端切换的路由器的吞吐量，这是另一个潜在的瓶颈。 另外，在传输过程中，我可以检查镜像服务器的交换机端口。
我不想回复客户：“好的，请确保您继续下载5分钟，以便我可以等待$ NMS_OF_CHOICE轮询接口”，而不是客户眼中可以接受的答案。 我可以给更多的scheme，但essentialy，抱怨客户是最重要的:)
我不是一个交换机devise师，所以就这个频率监控的成本而言，我不敢说。
我可以说的是，我已经遇到了这样的情况： 即使是一秒钟的时间也不够长，因为你可以在短于一秒的时间内超过缓冲器。 所以如果你想知道一个链接是否超时，我build议查看丢弃的数据包 （你也可以通过SNMP来监视这个数据包 ）。 如果你丢包（这里有一些没有问题，但很多不好），那么你要求比界面更能处理。 这甚至可能会在您的服务器上碰到交换机之前发生。 丢包的确切速率一般不重要，但是如果他们不断增加每个show interface你可能会在一个不好的地方。
就Cacti而言，这不是交换机或SNMP的限制。 SNMPlogging发送和接收的位数是递增计数器，所以如果每秒轮询一次，您将获得每秒的分辨率。 它的工作方式是每个样本的时间戳与当前计数一起进行。 然后以“每秒”为单位表示它的差异，但实际上每5分钟转换或expression为每秒一次。
如果您尝试每秒都轮询SNMP，则最好注意您的CPU。
您的界面正以全速传输和接收。 它实际上并没有以140Mbps的速度传输任何东西，这只是它在平均时间内的平均值。 实时的stream量利用对于你来说是无用的，因为在100％和0％的发送/接收之间，它会不断地翻来覆去。 如果你关心的是如何快速确定一个networking问题，那么我会build议@凯尔 – 布兰特上面所说的。 丢弃的数据包是过度使用链接的最佳指标。
SolarWinds实时接口监视器是networking工程师工具集的一部分，它能够通过SNMP轮询每5秒接口一次。
每5秒钟通过SNMP轮询networking接口不是pipe理员应该经常作为永久性监视解决scheme的一部分 。 但是，为了在特定的时间点进行监测，在less于60秒的轮询时间间隔内可以使用一些情况。
理解轮询时间间隔 – 随着时间的推移而变化，对于能够解释来自这些工具的数据至关重要。
作为一个虚构的（但是很多时候被看到的概念）的例子 ，一个在5秒间隔内注册90％利用率的接口可能不会导致最终用户感觉到的问题 – 然而， 在60秒间隔内50％利用率的相同接口可能实际上导致了最终用户感知的问题。
大多数pipe理员认为的错误是假设在60秒的时间间隔内50％的利用率在某个5秒的时间间隔内以某种方式“低于”90％的利用率。 它不是“小于” – 不是“大于”。 简单的答案是，由于间隔时间不同，使用率数据不能像对等数字一样进行比较。
要深入一点， 并展示极端情况会如何影响math运算 ，界面可以在100％利用率下运行30秒，然后静默30秒， 60秒间隔仍然是50％。 在100％利用率的30秒期间，最终用户应用经历了足够的分组丢失和/或延迟以超时/中断显示消息。
将其与5秒间隔内的90％利用率进行比较。 即使接口在100％利用率下4.5秒，然后静默0.5秒，导致在5秒间隔内利用率达到90％的情况下 – 分组丢失和/或延迟可能不足以导致最终用户应用程序才能做出反应。
以上是完全虚构的例子 – 然而，这个概念已经见证了很多次。 有意识地评估接口的过度使用/过度使用依赖于监视工具的知识，理解监视/轮询间隔以及解释监视/轮询工具的输出以及正在使用的应用程序的行为。
我写了一个期望的脚本来查询从“show int xxx”命令的输出中每秒发送/接收的字节数。 每秒之间的差异是通过界面的stream量。
基本脚本在这里： http : //tinyurl.com/c2sx2fc
这是我第一次期望的脚本，所以我的堆栈溢出线程在这里:) http://tinyurl.com/82gtk3e
我将添加丢弃和丢弃等function，并制作两个脚本，一个用于stream量，一个用于stream量。