第一:数据不精确

SNMP是基于查询的模式,网管系统通过定期发送snmp 查询消息,挨个儿问网络设备,或者服务器设备?

喂,你好么?

你哪里啥情况啊,接口流量是多少,CPU是多少,内占用率等?

就像大学时候的查房老太太,过一会儿就过来骚扰你一下。

但是这个查询,毕竟有个时间间隔,一般情况下我们都是配置5分钟,即300秒。

你要是以一天,或者数小时来看,5分钟的确很短。

所以一切都很好,很完美。

但是,偶尔就会出问题,我们以基于类似Cacti这种流量监控平台为例。

例如,客户抱怨在某个时间段网速很卡,有丢包现象。

然后工程师查看监控平台,没问题啊,我们监控平台上接口流量非常稳定。

没见着拥塞。

你说,这个时候,你是说客户刁蛮,还是说工程师说假话?

其实他们两个说的都没错。

让我们看下图:

(姜汁啊,嗯?你这个windows画图功底有待加强啊,不是一般的丑啊。)

上图中,绿色线条为监控系统认为的带宽,而顶上的黄 色 线 条代表接口带宽,上下波动的代表实时流量。

我猜,不用仔细说,你估计都知道大概了。

没错,当5分钟前SNMP第一次查询时,得到了第一个值,而第二次查询后,很碰巧,得到的值和第一次一样。

所以从SNMP的角度来看,貌似这5分钟之内,所占用的接口带宽没变化。

但是,真正的用户数据正如滔滔大浪,风云变幻。

你不知道在某一个时刻就会有突发数据,而突发两个字,正说明了他不是持续性的,是临时突然出现。

可是这突发流量仍然会造成网络接口丢包。

例如图中几个凸出。

可是在监控系统里面,却是风平浪静,岁月静好啊。

上面的例子可能稍微极端点,因为完全平直的监控平台流量线,不太可能。

但是很平滑,而不是突突突的突发流量,倒是实实在在发生的。

例如,下面又是另外一个反例:

下图中, 蓝色线条,很不幸,仍然是SNMP查询。

而红色线条,是某个监控协议吐出来的数据。

这里看出,红色线条非常贴近于真实流量了。

而粗红色线条圈起来的部分,则是某个故障导致流量暴跌。

可是,SNMP的定期查询,是看不到这些细节的。

在他的眼里,永远是丝般顺滑的直线。

第二:出力不讨好

上面说了,SNMP因为定期查询的原因,导致n多细节漏掉了。

有些小伙伴嘴角上扬,露出坏坏的笑容。

你这还不好解决,把SNMP查询时间调短一点不就行了么。

例如,1分钟,想爽一点30秒也成。

这叫当领导的动嘴,干活的动腿啊。

相信很多运维朋友肯定体会过,网络设备CPU定期飙高。

特别有规律,几分钟来一把。

而且赶巧的时,网管系统的服务器也特别心有灵犀,两者一起共振。

你高,我也高。

查来查去,就一个进程搞的事:SNMP。

这不用说,要么就是监控系统太多,这个系统负责查询一部分,那个系统负责查询另外一部分。

这网络设备吃不消啊。

要么是一个监控系统,但是查询内容太多。例如每查询一次,基本上把网络设备翻了个底朝天。

因为这些查询相应都是基于网络设备的路由引擎来处理,CPU能不高么?

所以,修改查询频率过高也不行。

第三:不靠谱

上面说完了snmp 查询,snmp的trap消息也是存在问题。

一般情况下我们都是用UDP来承载SNMP消息,那UDP的德行你们也懂的。

没问题还好,有啥问题了,直接当场把数据包丢了,关键是还不告诉你数据包被它丢了,这个品行值得怀疑。

一般协议还行,但是SNMP trap就这么一个啊。

你要是一个接口down掉了,网络设备就发一次,仅此一次trap消息这个独苗苗。

UDP照丢不误。

丢了以后,网络设备拍拍屁股说,反正我发出去了。

网管系统说,我没看见,不知道。

另外一个问题,我自己就遇到过,例如当一台监控平台设备同时管控上千台设备的时候。

这些不同时间段的snmp trap消息就像洪水一样涌入监控平台设备,可是当这些trap在进入监控平台内部snmp进程的时候,因为开源软件的某些bug,并发数不够了,导致trap在设备内部软件队列排着队,进场。

然后滑稽的一幕出现了,2个小时前一台网络设备挂了,网管中心监控人员开心的吃着火锅唱着歌。直到有人冲到办公室说,我们网断了,什么情况?

没有啊,你看监控平台,全是绿油油的灯,多美。

两小时以后,有人大呼,设备down了。

那回到问题本身,假设现在有一个重要接口down掉了,靠SNMP你怎么解决?

A. 咱把查询时间调节到每秒查询吧?

B. 等着SNMP trap消息吧?

你说上面两个,你选择哪个?

第四:不完全兼容

你是否遇到如下场景:

一早上,什么事情没干,光百度了。

百度什么?

关键字:某某设备的MIB库?

或者,关键字:某某设备SNMP 查询某个数值。

这些事情,真心烦心。

到最后怎么解决的?

唉,还能怎么解决,敲命令行收集呗。

要是会编程,就写个程序来敲命令收集呗。

要是当领导了,就找个会写代码的工程师,写个程序来敲命令收集呗。

第五:毫无人性的OID值

问你个问题,你知道这是什么?

.1.3.6.1.2.1.2.1.8

答:SNMP OID值。

再问?

什么OID值?

如果你说:这指代IF-MIB的接口状态,ifOperStatus

恭喜你,你可以进入非正常人类研究中心参观了。

我相信你也玩过snmpwalk,你walk一把出来的全是一堆非人类语言,密密麻麻的数字。

你说上班的心情怎么能好?

SNMP 小结

不敢再说多了,说多了都是在拉仇恨,毕竟包括我在内很多人都还在依靠着SNMP,不伺候好了,小心给你罢工。

综上所述,SNMP在现如今的网络环境下,的确遇到了瓶颈。

尤其是网络规模日益扩大的今天。

所以,应了那句话:

有些SNMP还活着,但是其实它已经死了。。

怎么办?

从拉(Pull) 到推(Push)的变化。

我们能不能换个角度,把传统的从监控系统到网络设备”拉“数据的方法,变为网络设备主动向监控系统”推“数据的方法?

例如,以SNMP 为例的设备状态获取方法是拉的方法,即所谓的查询。

这就导致了网络设备被动响应,因为你不知道什么时候SNMP查询会飞过来,等它来了,网络设备不得不分配资源处理。

但是,换个角度,如果采用主动上报的方式,这个问题就解决了。

因为主动上报,网络设备握有主动权,开发人员可以根据实际运行情况调整设备资源利用率和负载。

为了方便阅读,下面是两者的一个简单对比:

不用说,一番PK下来,除了灵活性败给被动查询,其他方面主动上报”推“的方式优势巨大。

未来趋势:Streaming Telemetry 流遥测技术

这个名字很吊,流遥测技术。

其实,简单来讲。它就是实现了上述“推”数据的方法。

那如何高效的完成“推”的这个动作呢?

Streaming Telemetry有如下特点:

1. 基于数据层面的数据上报

传统的SNMP,不管是查询还是Trap,都是路由引擎,控制层面来处理。

但是Streaming Telemetry则可以借助于厂商支持,在硬件板卡ASIC层面植入代码,直接从板卡导出实时数据。

而板卡导出的数据是按照线速发送,从而使得上层的路由引擎专注于处理协议和路由计算等。

如下图所示:

2.高扩展性

基于第一条数据层面的原因,Stream Telemetry的扩展性大大增强。

例如下面这张图是一张CPU的利用率图。(设备型号未知)

大致看来,CPU利用率徘徊在8%左右。

但是,这台设备配置了Stream Telemetry主动上报。

你猜,它都上报了多少内容?

下面是数据:

  1. 每15秒上报一次
  2. 超过60种指标上报
  3. 包含500多个上报类型
  4. 176个万兆接口的输入,输出统计,error数,Qos队列数统计。
  5. 每一个接口都包含IPv4和IPv6两种数据类型。
  6. 最后以及200个MPLS LSP的字节数和数据包数。

太恐怖了,SNMP与之相比,瞬间弱爆了。

这一张图片红色线条,在上面提到过是某协议吐出的数据。

不用说,你都知道了。

这就是Streaming Telemetry吐出的数据。

3. 自动支持 Devops运维自动化

Streaming Telemetry因为两大优势,自动对接了当前流行的技术,例如运维自动化技术。

一方面,Streaming Telemetry监控平台收集到的数据接近于即时信息,所以Devops运维自动化工程师可以有很多不同的玩法,例如根据当前流量数据,结合SDN来自动调整数据转发路径。

另外一方面,Streaming Telemetry采用的数据格式都是当今很流行的标准格式和模型。例如JSON,NETCONF,以及YANG模型。

所以,简单来说,这是一个顺应时代的工具和技术。

4. 多选择

目前Streaming Telemetry技术,有两个选择。

一个是Sflow

而另外一个是OpenConfig Telemetry

(已经在Google部署,30%的厂商设备已经开启Streaming Telemetry,每秒百万级别的更新量。)