第一：數據不精確
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主動上報。
你猜，它都上報了多少內容？
下面是數據：
- 每15秒上報一次
- 超過60種指標上報
- 包含500多個上報類型
- 176個萬兆接口的輸入，輸出統計，error數，Qos隊列數統計。
- 每個接口都包含IPv4和IPv6兩種數據類型。
- 最後以及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，每秒百萬級別的更新量。）