路人甲：姜汁哥，聽說你專欄賣得很火？
讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：主機域名、虛擬空間、營銷軟件、網(wǎng)站建設、泰寧網(wǎng)站維護、網(wǎng)站推廣。還行吧，感謝大家的認可。
路人甲：你這賺了點小錢，就跑路了？上次見你發(fā)文章，轉眼已是n年。
沒跑路，沒跑路，我現(xiàn)在夜以繼日的在為《網(wǎng)工2.0晉級攻略 - 零基礎入門Ansible/Python》趕稿子呢。（底部有彩蛋?。?/p>
路人甲：真會裝。。。。
琢磨了半天，才想出來這么個用2B鉛筆寫的，廣告成分極大開場白，最近一忙專欄，就沒空更新博客，對不住我的朋友們了。
今天我想和大家聊一個關乎于多年江湖恩怨的話題。
喔喔喔，等下，先別急著扔斧頭，大哥，這話不是我說的，是別人說的。
我知道你對SNMP情誼很深，你的網(wǎng)絡全都是靠SNMP罩著呢。
這貨要罷工了，估計老板馬上就去你家了，估計你新婚之夜也得扛筆記本去機房了。
但是，就像美帝亡我之心不似，很多人早已對SNMP起了歹心，一心想把它干掉。
我今天來的目的，就是想給大家說說說，別人對SNMP都怎么看的，他們如何計劃把SNMP干掉的。
畢竟，有些事情一個巴掌拍不響，肯定事出有因。
我們先別急著反對，看看他們說有沒有道理。
沒道理了，再飛斧頭。
SNMP是基于查詢的模式，網(wǎng)管系統(tǒng)通過定期發(fā)送snmp 查詢消息，挨個兒問網(wǎng)絡設備，或者服務器設備？
喂，你好么？
你哪里啥情況啊，接口流量是多少，CPU是多少，內占用率等？
就像大學時候的查房老太太，過一會兒就過來騷擾你一下。
但是這個查詢，畢竟有個時間間隔，一般情況下我們都是配置5分鐘，即300秒。
你要是以一天，或者數(shù)小時來看，5分鐘的確很短。
所以一切都很好，很完美。
但是，偶爾就會出問題，我們以基于類似Cacti這種流量監(jiān)控平臺為例。
例如，客戶抱怨在某個時間段網(wǎng)速很卡，有丟包現(xiàn)象。
然后工程師查看監(jiān)控平臺，沒問題啊，我們監(jiān)控平臺上接口流量非常穩(wěn)定。
沒見著擁塞。
你說，這個時候，你是說客戶刁蠻，還是說工程師說假話？
其實他們兩個說的都沒錯。
讓我們看下圖：
（姜汁啊，嗯？你這個windows畫圖功底有待加強啊，不是一般的丑啊。）
上圖中，綠色線條為監(jiān)控系統(tǒng)認為的帶寬，而頂上的黃 色 線 條代表接口帶寬，上下波動的代表實時流量。
我猜，不用仔細說，你估計都知道大概了。
沒錯，當5分鐘前SNMP第一次查詢時，得到了第一個值，而第二次查詢后，很碰巧，得到的值和第一次一樣。
所以從SNMP的角度來看，貌似這5分鐘之內，所占用的接口帶寬沒變化。
但是，真正的用戶數(shù)據(jù)正如滔滔大浪，風云變幻。
你不知道在某一個時刻就會有突發(fā)數(shù)據(jù)，而突發(fā)兩個字，正說明了他不是持續(xù)性的，是臨時突然出現(xiàn)。
可是這突發(fā)流量仍然會造成網(wǎng)絡接口丟包。
例如圖中幾個凸出。
可是在監(jiān)控系統(tǒng)里面，卻是風平浪靜，歲月靜好啊。
上面的例子可能稍微極端點，因為完全平直的監(jiān)控平臺流量線，不太可能。
但是很平滑，而不是突突突的突發(fā)流量，倒是實實在在發(fā)生的。
例如，下面又是另外一個反例：
下圖中， 藍色線條，很不幸，仍然是SNMP查詢。
而紅色線條，是某個監(jiān)控協(xié)議吐出來的數(shù)據(jù)。
這里看出，紅色線條非常貼近于真實流量了。
而粗紅色線條圈起來的部分，則是某個故障導致流量暴跌。
可是，SNMP的定期查詢，是看不到這些細節(jié)的。
在他的眼里，永遠是絲般順滑的直線。
上面說了，SNMP因為定期查詢的原因，導致n多細節(jié)漏掉了。
有些小伙伴嘴角上揚，露出壞壞的笑容。
你這還不好解決，把SNMP查詢時間調短一點不就行了么。
例如，1分鐘，想爽一點30秒也成。
這叫當領導的動嘴，干活的動腿啊。
相信很多運維朋友肯定體會過，網(wǎng)絡設備CPU定期飆高。
特別有規(guī)律，幾分鐘來一把。
而且趕巧的時，網(wǎng)管系統(tǒng)的服務器也特別心有靈犀，兩者一起共振。
你高，我也高。
查來查去，就一個進程搞的事：SNMP。
這不用說，要么就是監(jiān)控系統(tǒng)太多，這個系統(tǒng)負責查詢一部分，那個系統(tǒng)負責查詢另外一部分。
這網(wǎng)絡設備吃不消啊。
要么是一個監(jiān)控系統(tǒng)，但是查詢內容太多。例如每查詢一次，基本上把網(wǎng)絡設備翻了個底朝天。
因為這些查詢相應都是基于網(wǎng)絡設備的路由引擎來處理，CPU能不高么？
所以，修改查詢頻率過高也不行。
上面說完了snmp 查詢，snmp的trap消息也是存在問題。
一般情況下我們都是用UDP來承載SNMP消息，那UDP的德行你們也懂的。
沒問題還好，有啥問題了，直接當場把數(shù)據(jù)包丟了，關鍵是還不告訴你數(shù)據(jù)包被它丟了，這個品行值得懷疑。
一般協(xié)議還行，但是SNMP trap就這么一個啊。
你要是一個接口down掉了，網(wǎng)絡設備就發(fā)一次，僅此一次trap消息這個獨苗苗。
UDP照丟不誤。
丟了以后，網(wǎng)絡設備拍拍屁股說，反正我發(fā)出去了。
網(wǎng)管系統(tǒng)說，我沒看見，不知道。
最后誰倒霉？
搞運維的工程師么，還用說。
網(wǎng)絡世界，其實也有國企。
另外一個問題，我自己就遇到過，例如當一臺監(jiān)控平臺設備同時管控上千臺設備的時候。
這些不同時間段的snmp trap消息就像洪水一樣涌入監(jiān)控平臺設備，可是當這些trap在進入監(jiān)控平臺內部snmp進程的時候，因為開源軟件的某些bug，并發(fā)數(shù)不夠了，導致trap在設備內部軟件隊列排著隊，進場。
然后滑稽的一幕出現(xiàn)了，2個小時前一臺網(wǎng)絡設備掛了，網(wǎng)管中心監(jiān)控人員開心的吃著火鍋唱著歌。直到有人沖到辦公室說，我們網(wǎng)斷了，什么情況？
沒有啊，你看監(jiān)控平臺，全是綠油油的燈，多美。
兩小時以后，有人大呼，設備down了。
那回到問題本身，假設現(xiàn)在有一個重要接口down掉了，靠SNMP你怎么解決？
A. 咱把查詢時間調節(jié)到每秒查詢吧？
B. 等著SNMP trap消息吧？
你說上面兩個，你選擇哪個？
你是否遇到如下場景：
一早上，什么事情沒干，光百度了。
百度什么？
關鍵字：某某設備的MIB庫？
或者，關鍵字：某某設備SNMP 查詢某個數(shù)值。
這些事情，真心煩心。
到最后怎么解決的？
唉，還能怎么解決，敲命令行收集唄。
要是會編程，就寫個程序來敲命令收集唄。
要是當領導了，就找個會寫代碼的工程師，寫個程序來敲命令收集唄。
問你個問題，你知道這是什么？
.1.3.6.1.2.1.2.1.8
答：SNMP OID值。
再問？
什么OID值？
如果你說：這指代IF-MIB的接口狀態(tài)，ifOperStatus
恭喜你，你可以進入非正常人類研究中心參觀了。
我相信你也玩過snmpwalk，你walk一把出來的全是一堆非人類語言，密密麻麻的數(shù)字。
你說上班的心情怎么能好？
不敢再說多了，說多了都是在拉仇恨，畢竟包括我在內很多人都還在依靠著SNMP，不伺候好了，小心給你罷工。
綜上所述，SNMP在現(xiàn)如今的網(wǎng)絡環(huán)境下，的確遇到了瓶頸。
尤其是網(wǎng)絡規(guī)模日益擴大的今天。
所以，應了那句話：
有些SNMP還活著，但是其實它已經(jīng)死了。。
怎么辦？
我們能不能換個角度，把傳統(tǒng)的從監(jiān)控系統(tǒng)到網(wǎng)絡設備”拉“數(shù)據(jù)的方法，變?yōu)榫W(wǎng)絡設備主動向監(jiān)控系統(tǒng)”推“數(shù)據(jù)的方法？
例如，以SNMP 為例的設備狀態(tài)獲取方法是拉的方法，即所謂的查詢。
這就導致了網(wǎng)絡設備被動響應，因為你不知道什么時候SNMP查詢會飛過來，等它來了，網(wǎng)絡設備不得不分配資源處理。
但是，換個角度，如果采用主動上報的方式，這個問題就解決了。
因為主動上報，網(wǎng)絡設備握有主動權，開發(fā)人員可以根據(jù)實際運行情況調整設備資源利用率和負載。
為了方便閱讀，下面是兩者的一個簡單對比：
不用說，一番PK下來，除了靈活性敗給被動查詢，其他方面主動上報”推“的方式優(yōu)勢巨大。
這個名字很吊，流遙測技術。
其實，簡單來講。它就是實現(xiàn)了上述“推”數(shù)據(jù)的方法。
那如何高效的完成“推”的這個動作呢？
Streaming Telemetry有如下特點：
傳統(tǒng)的SNMP，不管是查詢還是Trap，都是路由引擎，控制層面來處理。
但是Streaming Telemetry則可以借助于廠商支持，在硬件板卡ASIC層面植入代碼，直接從板卡導出實時數(shù)據(jù)。
而板卡導出的數(shù)據(jù)是按照線速發(fā)送，從而使得上層的路由引擎專注于處理協(xié)議和路由計算等。
如下圖所示：
基于第一條數(shù)據(jù)層面的原因，Stream Telemetry的擴展性大大增強。
例如下面這張圖是一張CPU的利用率圖。（設備型號未知）
大致看來，CPU利用率徘徊在8%左右。
但是，這臺設備配置了Stream Telemetry主動上報。
你猜，它都上報了多少內容？
下面是數(shù)據(jù)：
太恐怖了，SNMP與之相比，瞬間弱爆了。
這一張圖片紅色線條，在上面提到過是某協(xié)議吐出的數(shù)據(jù)。
不用說，你都知道了。
這就是Streaming Telemetry吐出的數(shù)據(jù)。
Streaming Telemetry因為兩大優(yōu)勢，自動對接了當前流行的技術，例如運維自動化技術。
一方面，Streaming Telemetry監(jiān)控平臺收集到的數(shù)據(jù)接近于即時信息，所以Devops運維自動化工程師可以有很多不同的玩法，例如根據(jù)當前流量數(shù)據(jù)，結合SDN來自動調整數(shù)據(jù)轉發(fā)路徑。
另外一方面，Streaming Telemetry采用的數(shù)據(jù)格式都是當今很流行的標準格式和模型。例如JSON，NETCONF，以及YANG模型。
所以，簡單來說，這是一個順應時代的工具和技術。
目前Streaming Telemetry技術，有兩個選擇。
一個是Sflow
而另外一個是OpenConfig Telemetry
（已經(jīng)在Google部署，30%的廠商設備已經(jīng)開啟Streaming Telemetry，每秒百萬級別的更新量。）
上面兩家已經(jīng)有很多廠商跟進了。
例如思科和Juniper針對上面兩種都可以做相應的配置。
感興趣朋友可以去看看官方配置文檔。
此篇文章先打個頭哨。
如果你對于sflow，或者Openconfig干的事兒很感興趣。
請留言，我下篇文章針對性的一起聊細節(jié)。
說了這么多，最后聊聊情懷。
也就是最近5-6年的時光，計算機網(wǎng)絡這個行業(yè)，已經(jīng)算是翻天覆地的變化了。
各種新技術層出不窮，百花齊放，百家爭鳴。
而當我不斷觸碰到這些新技術時，心里不光被觸動，更重要的是一種時刻存在的危機感。
所以，我希望自己能夠憑借有限的時間和精力，構筑一個小小的信息橋梁，不管你是因為英語這個鴻溝，還是其他原因也好，我們一起為未來的到來，一起努力。
順便做個小小的推廣：
如果你不知道上面說的JSON，NETCONF，YANG模型是什么意思？
如果你想學習自動化？
或者，你就是想找一群志同道合的好xxx（原文是 基 友，和諧版本為×××），暢談網(wǎng)絡技術。而不是一次一次的加入一個死寂一般的群。
那么，我想我的專欄 《網(wǎng)工2.0晉級攻略 - 零基礎入門Ansible/Python》會滿足你上面所有需求。
安卓小程序端“51CTO訂閱專欄”，訂閱專欄更優(yōu)惠！
加入我們，迎接未來。
末了，就以崔健《不是我不明白 這世界變化快》的歌詞結尾，國慶快樂。
重慶分公司
重慶分公司
不是我不明白
- 崔健
放眼看那座座高樓如同那稻麥
看眼前是人的海洋和交通的堵塞
我左看右看前看后看還是看不過來
這個這個那個那個越看越奇怪
過去我不知什么是寬闊胸懷
過去我不知世界有很多奇怪
過去我幻想的未來可不是現(xiàn)在
現(xiàn)在才似乎清楚什么是未來
噢……
不是我不明白,這世界變化快另外有需要云服務器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
