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