路人甲:薑汁哥,據說你專欄賣得很火?編程
還行吧,感謝你們的承認。小程序
路人甲:你這賺了點小錢,就跑路了?上次見你發文章,轉眼已經是n年。windows
沒跑路,沒跑路,我如今夜以繼日的在爲《網工2.0晉級攻略 - 零基礎入門Ansible/Python》趕稿子呢。(底部有彩蛋!)服務器
路人甲:真會裝。。。。網絡
琢磨了半天,纔想出來這麼個用2B鉛筆寫的,廣告成分極大開場白,最近一忙專欄,就沒空更新博客,對不住個人朋友們了。併發
今天我想和你們聊一個關乎於多年江湖恩怨的話題。運維
喔喔喔,等下,先別急着扔斧頭,大哥,這話不是我說的,是別人說的。ide
我知道你對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訂閱專欄」,訂閱專欄更優惠!
加入咱們,迎接將來。
末了,就以崔健《不是我不明白 這世界變化快》的歌詞結尾,國慶快樂。
不是我不明白 - 崔健 放眼看那座座高樓如同那稻麥 看眼前是人的海洋和交通的堵塞 我左看右看前看後看仍是看不過來 這個這個那個那個越看越奇怪 過去我不知什麼是寬闊胸懷 過去我不知世界有不少奇怪 過去我幻想的將來可不是如今 如今才彷佛清楚什麼是將來 噢…… 不是我不明白,這世界變化快