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》会知足你上面全部需求。

彩蛋

安卓小程序端“51CTO订阅专栏”，订阅专栏更优惠！

加入咱们，迎接将来。

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

不是我不明白
- 崔健

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

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

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

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

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

过去我不知世界有不少奇怪

过去我幻想的将来可不是如今

如今才彷佛清楚什么是将来

噢……

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