SNMP 已死 - Streaming Telemetry 流遥测技术 荐

路人甲：姜汁哥，听说你专栏卖得很火？

还行吧，感谢大家的认可。

路人甲：你这赚了点小钱，就跑路了？上次见你发文章，转眼已是n年。

没跑路，没跑路，我现在夜以继日的在为《网工2.0晋级攻略 - 零基础入门Ansible/Python》赶稿子呢。

路人甲：真会装。。。。

琢磨了半天，才想出来这么个用2B铅笔写的，广告成分极大开场白，最近一忙专栏，就没空更新博客，对不住我的朋友们了。

今天我想和大家聊一个关乎于多年江湖恩怨的话题。

SNMP已死！

喔喔喔，等下，先别急着扔斧头，大哥，这话不是我说的，是别人说的。

我知道你对SNMP情谊很深，你的网络全都是靠SNMP罩着呢。

这货要罢工了，估计老板马上就去你家了，估计你新婚之夜也得扛笔记本去机房了。

但是，就像美帝亡我之心不似，很多人早已对SNMP起了歹心，一心想把它干掉。

我今天来的目的，就是想给大家说说说，别人对SNMP都怎么看的，他们如何计划把SNMP干掉的。

毕竟，有些事情一个巴掌拍不响，肯定事出有因。

我们先别急着反对，看看他们说有没有道理。

没道理了，再飞斧头。

第一：数据不精确

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，每秒百万级别的更新量。）

上面两家已经有很多厂商跟进了。

例如思科和Juniper针对上面两种都可以做相应的配置。

感兴趣朋友可以去看看官方配置文档。

此篇文章先打个头哨。

如果你对于sflow，或者Openconfig干的事儿很感兴趣。

请留言，我下篇文章针对性的一起聊细节。

最后

说了这么多，最后聊聊情怀。

也就是最近5-6年的时光，计算机网络这个行业，已经算是翻天覆地的变化了。

各种新技术层出不穷，百花齐放，百家争鸣。

而当我不断触碰到这些新技术时，心里不光被触动，更重要的是一种时刻存在的危机感。

所以，我希望自己能够凭借有限的时间和精力，构筑一个小小的信息桥梁，不管你是因为英语这个鸿沟，还是其他原因也好，我们一起为未来的到来，一起努力。

顺便做个小小的推广：

如果你不知道上面说的JSON，NETCONF，YANG模型是什么意思？

如果你想学习自动化？

或者，你就是想找一群志同道合的好xxx（原文是 基 友，和谐版本为×××），畅谈网络技术。而不是一次一次的加入一个死寂一般的群。

那么，我想我的专栏 《网工2.0晋级攻略 - 零基础入门Ansible/Python》会满足你上面所有需求。

加入我们，迎接未来。

末了，就以崔健《不是我不明白 这世界变化快》的歌词结尾，国庆快乐。

不是我不明白
- 崔健

放眼看那座座高楼如同那稻麦

看眼前是人的海洋和交通的堵塞

我左看右看前看后看还是看不过来

这个这个那个那个越看越奇怪

过去我不知什么是宽阔胸怀

过去我不知世界有很多奇怪

过去我幻想的未来可不是现在

现在才似乎清楚什么是未来

噢……

不是我不明白,这世界变化快