路人甲：姜汁哥，听说你专栏卖得很火？
还行吧，感谢大家的认可。
路人甲：你这赚了点小钱，就跑路了？上次见你发文章，转眼已是n年。
没跑路，没跑路，我现在夜以继日的在为《网工2.0晋级攻略 - 零基础入门Ansible/Python》赶稿子呢。（底部有彩蛋！）
路人甲：真会装。。。。
琢磨了半天，才想出来这么个用2B铅笔写的，广告成分极大开场白，最近一忙专栏，就没空更新博客，对不住我的朋友们了。
今天我想和大家聊一个关乎于多年江湖恩怨的话题。
喔喔喔，等下，先别急着扔斧头，大哥，这话不是我说的，是别人说的。
我知道你对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 查询某个数值。
这些事情，真心烦心。
到最后怎么解决的？
唉，还能怎么解决，敲命令行收集呗。
要是会编程，就写个程序来敲命令收集呗。
要是当领导了，就找个会写代码的工程师，写个程序来敲命令收集呗。
问你个问题，你知道这是什么？
.1.3.6.1.2.1.2.1.8
答：SNMP OID值。
再问？
什么OID值？
如果你说：这指代IF-MIB的接口状态，ifOperStatus
恭喜你，你可以进入非正常人类研究中心参观了。
我相信你也玩过snmpwalk，你walk一把出来的全是一堆非人类语言，密密麻麻的数字。
你说上班的心情怎么能好？
不敢再说多了，说多了都是在拉仇恨，毕竟包括我在内很多人都还在依靠着SNMP，不伺候好了，小心给你罢工。
综上所述，SNMP在现如今的网络环境下，的确遇到了瓶颈。
尤其是网络规模日益扩大的今天。
所以，应了那句话：
有些SNMP还活着，但是其实它已经死了。。
怎么办？
我们能不能换个角度，把传统的从监控系统到网络设备”拉“数据的方法，变为网络设备主动向监控系统”推“数据的方法？
例如，以SNMP 为例的设备状态获取方法是拉的方法，即所谓的查询。
这就导致了网络设备被动响应，因为你不知道什么时候SNMP查询会飞过来，等它来了，网络设备不得不分配资源处理。
但是，换个角度，如果采用主动上报的方式，这个问题就解决了。
因为主动上报，网络设备握有主动权，开发人员可以根据实际运行情况调整设备资源利用率和负载。
为了方便阅读，下面是两者的一个简单对比：
不用说，一番PK下来，除了灵活性败给被动查询，其他方面主动上报”推“的方式优势巨大。
这个名字很吊，流遥测技术。
其实，简单来讲。它就是实现了上述“推”数据的方法。
那如何高效的完成“推”的这个动作呢？
Streaming Telemetry有如下特点：
传统的SNMP，不管是查询还是Trap，都是路由引擎，控制层面来处理。
但是Streaming Telemetry则可以借助于厂商支持，在硬件板卡ASIC层面植入代码，直接从板卡导出实时数据。
而板卡导出的数据是按照线速发送，从而使得上层的路由引擎专注于处理协议和路由计算等。
如下图所示：
基于第一条数据层面的原因，Stream Telemetry的扩展性大大增强。
例如下面这张图是一张CPU的利用率图。（设备型号未知）
大致看来，CPU利用率徘徊在8%左右。
但是，这台设备配置了Stream Telemetry主动上报。
你猜，它都上报了多少内容？
下面是数据：
太恐怖了，SNMP与之相比，瞬间弱爆了。
这一张图片红色线条，在上面提到过是某协议吐出的数据。
不用说，你都知道了。
这就是Streaming Telemetry吐出的数据。
Streaming Telemetry因为两大优势，自动对接了当前流行的技术，例如运维自动化技术。
一方面，Streaming Telemetry监控平台收集到的数据接近于即时信息，所以Devops运维自动化工程师可以有很多不同的玩法，例如根据当前流量数据，结合SDN来自动调整数据转发路径。
另外一方面，Streaming Telemetry采用的数据格式都是当今很流行的标准格式和模型。例如JSON，NETCONF，以及YANG模型。
所以，简单来说，这是一个顺应时代的工具和技术。
目前Streaming Telemetry技术，有两个选择。
一个是Sflow
而另外一个是OpenConfig Telemetry
（已经在Google部署，30%的厂商设备已经开启Streaming Telemetry，每秒百万级别的更新量。）
上面两家已经有很多厂商跟进了。
例如思科和Juniper针对上面两种都可以做相应的配置。
感兴趣朋友可以去看看官方配置文档。
此篇文章先打个头哨。
如果你对于sflow，或者Openconfig干的事儿很感兴趣。
请留言，我下篇文章针对性的一起聊细节。
说了这么多，最后聊聊情怀。
也就是最近5-6年的时光，计算机网络这个行业，已经算是翻天覆地的变化了。
各种新技术层出不穷，百花齐放，百家争鸣。
而当我不断触碰到这些新技术时，心里不光被触动，更重要的是一种时刻存在的危机感。
所以，我希望自己能够凭借有限的时间和精力，构筑一个小小的信息桥梁，不管你是因为英语这个鸿沟，还是其他原因也好，我们一起为未来的到来，一起努力。
顺便做个小小的推广：
如果你不知道上面说的JSON，NETCONF，YANG模型是什么意思？
如果你想学习自动化？
或者，你就是想找一群志同道合的好xxx（原文是 基 友，和谐版本为×××），畅谈网络技术。而不是一次一次的加入一个死寂一般的群。
那么，我想我的专栏 《网工2.0晋级攻略 - 零基础入门Ansible/Python》会满足你上面所有需求。
安卓小程序端“51CTO订阅专栏”，订阅专栏更优惠！
加入我们，迎接未来。
末了，就以崔健《不是我不明白 这世界变化快》的歌词结尾，国庆快乐。
不是我不明白
- 崔健
放眼看那座座高楼如同那稻麦
看眼前是人的海洋和交通的堵塞
我左看右看前看后看还是看不过来
这个这个那个那个越看越奇怪
过去我不知什么是宽阔胸怀
过去我不知世界有很多奇怪
过去我幻想的未来可不是现在
现在才似乎清楚什么是未来
噢……
不是我不明白,这世界变化快
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
