網(wǎng)絡(luò)運維一直倡導要可視化，并且在實踐中不斷優(yōu)化，怎耐可視化的技術(shù)寥寥無幾，網(wǎng)絡(luò)技術(shù)經(jīng)過了五十年的演進變化，可視化依然要依托SNMP、鏡像這些老技術(shù)。SNMP能監(jiān)控到網(wǎng)絡(luò)的運行信息實在有限，從外部應用發(fā)起的請求獲取網(wǎng)絡(luò)狀態(tài)信息的SNMP協(xié)議，無法實時反映網(wǎng)絡(luò)的狀態(tài)。比如：時延、轉(zhuǎn)發(fā)路徑、緩存和丟包，這些都無法通過SNMP獲知，網(wǎng)絡(luò)對運維的人員來講，就是一個黑盒子，傳統(tǒng)的監(jiān)控手段無法看透黑盒子。所以，長期以來網(wǎng)絡(luò)運維的可視化算不上真正的可視化，那些通過大屏將端口流量、設(shè)備CPU、Memory等運行狀態(tài)顯示出來只不過是可視化的一部分，網(wǎng)絡(luò)真實的運行狀態(tài)還未能顯現(xiàn)出來。最近，網(wǎng)絡(luò)可視化還真出現(xiàn)不少新技術(shù)，頗為引人注目，也許是未來網(wǎng)絡(luò)運維的技術(shù)演進方向，本文接下來就詳細講講。

Sflow(RFC3176)

Sflow其實算不上新技術(shù)，這幾年幾乎已經(jīng)所有的網(wǎng)絡(luò)設(shè)備都能支持。Sflow實現(xiàn)了網(wǎng)絡(luò)流量的采樣和推送，通過Sflow采集最原始的數(shù)據(jù)信息，以IP報文格式的形式發(fā)往服務器，由專門的分析工具解析，然后根據(jù)這些采集的數(shù)據(jù)進行統(tǒng)計分析。Sflow是采樣方式收集數(shù)據(jù)，采樣比越高獲取的數(shù)據(jù)越真實，但采樣比越高，設(shè)備CPU壓力就越大。Sflow采樣報文是經(jīng)過網(wǎng)絡(luò)設(shè)備CPU收集，然后再發(fā)向服務器的，采集的數(shù)據(jù)太多，會對網(wǎng)絡(luò)設(shè)備CPU形成攻擊，可能影響設(shè)備的正常協(xié)議處理，影響業(yè)務。所以，要謹慎使用Sflow，即便使用也要根據(jù)設(shè)備流量大小，確認好采樣比。Sflow使用的局限性讓人想到用硬件實現(xiàn)數(shù)據(jù)采集，比如FPGA、Netstream硬件設(shè)備，這樣采集數(shù)據(jù)性能雖會有很大提升，但運維的投入成本(購入支持FPGA的板卡或Netstream硬件設(shè)備)會上去。另一方面，網(wǎng)絡(luò)設(shè)備的CPU、Memory、網(wǎng)絡(luò)擁塞和網(wǎng)絡(luò)事件的日志信息也無法通過Sflow實時傳遞出來。所以，Sflow技術(shù)一直不溫不火，并未得到絕大多數(shù)人的認可，使用時還要配合著SNMP來用，一個網(wǎng)絡(luò)中要部署多個監(jiān)控系統(tǒng)，可視化看到的都是部分網(wǎng)絡(luò)，并非全部。

gRPC(Google Remote Procedure Calls，谷歌遠程過程調(diào)用)

網(wǎng)絡(luò)運維在可視化上的窘態(tài)引起了互聯(lián)網(wǎng)技術(shù)人員的注意，谷歌發(fā)布了一個開源的RPC框架，RPC定義了客戶端和服務端進行通信的數(shù)據(jù)結(jié)構(gòu)，服務端提供的服務等，然后編譯生成相應的代碼供客戶端和服務端使用，gRPC是RPC框架正式的實現(xiàn)版本，在2015年初開源的通信框架。gRPC采用了protocol buffer來做數(shù)據(jù)的序列化與反序列化，用http 2作為數(shù)據(jù)傳輸協(xié)議，性能更優(yōu)。在網(wǎng)絡(luò)設(shè)備上集成gRPC應用，網(wǎng)絡(luò)設(shè)備就相當于gRPC客戶端角色，監(jiān)控服務器相當于gRPC服務器角色，網(wǎng)絡(luò)設(shè)備主動向監(jiān)控服務器發(fā)起gRPC通道建立和連接。gRPC可以靈活定義數(shù)據(jù)格式和數(shù)據(jù)推送的閾值，從而實現(xiàn)網(wǎng)絡(luò)設(shè)備自身運行狀態(tài)的主動推送數(shù)據(jù)能力，實現(xiàn)周期性推送網(wǎng)絡(luò)設(shè)備豐富的運行狀態(tài)，尤其當發(fā)生緩存不足導致的丟包時，也會實時通知給監(jiān)控服務器，實現(xiàn)網(wǎng)絡(luò)運行數(shù)據(jù)的可視化。表1列舉了gRPC與傳統(tǒng)可視化技術(shù)的對比：

顯然，gRPC具有響應速度快，實時性高，采集數(shù)據(jù)全面的優(yōu)點。

INT(In-band Network Telemetry帶內(nèi)網(wǎng)絡(luò)遙測)

INT是由Barefoot、Arista、Dell、Intel和VMWARE共同提出的技術(shù)。INT是被設(shè)計用來收集和報告網(wǎng)絡(luò)狀態(tài)的一個框架，它通過數(shù)據(jù)平面實現(xiàn)，不需要控制平面的干涉，F(xiàn)acebook根據(jù)這個協(xié)議和相應廠商的網(wǎng)絡(luò)設(shè)備設(shè)計了一套系統(tǒng)，未來可能會開源。INT的思想是在第一跳的網(wǎng)絡(luò)設(shè)備上收到相應報文，對其進行封裝特定報文，然后扔給下一跳，直到最后一跳網(wǎng)絡(luò)設(shè)備，每一跳網(wǎng)絡(luò)設(shè)備都會收集相應的信息，封在報文里面。最后，在最后一跳網(wǎng)絡(luò)設(shè)備剝離報文里面收集到的信息，然后把原始報文扔給服務器，收集到的網(wǎng)絡(luò)設(shè)備信息扔給監(jiān)控端處理。這樣即不影響正常業(yè)務轉(zhuǎn)發(fā)，又能收集到經(jīng)過網(wǎng)絡(luò)設(shè)備的信息，在黑盒不知道網(wǎng)絡(luò)拓撲的情況下還能探測出網(wǎng)絡(luò)拓撲。初步協(xié)議給定的有：交換機ID、入端口信息、入端口時間戳、出端口ID、出端口時間戳、出端口鏈路利用率，緩存信息。INT是一個類似OAM的協(xié)議，INT根據(jù)沿路設(shè)備的信息，就能夠知道報文怎么走的，哪里有性能瓶頸，解決了網(wǎng)絡(luò)轉(zhuǎn)發(fā)路徑和轉(zhuǎn)發(fā)時延不可見的問題。要注意的是：“INT推薦在數(shù)據(jù)面處理，不推薦控制面處理以體現(xiàn)真實情況。”利用INT技術(shù)能很快定位網(wǎng)絡(luò)丟包和延遲問題，通過軟件打標記是無法實現(xiàn)INT的高效處理的，必須需要網(wǎng)絡(luò)設(shè)備硬件支持。

網(wǎng)絡(luò)運維的可視化還有很長的路要走，sflow、gRPC、INT等都是可視化具體實現(xiàn)技術(shù)，尤其gRPC和INT技術(shù)還沒有得到廣泛使用，現(xiàn)有數(shù)據(jù)中心的絕大部分設(shè)備還無法支持這種新技術(shù)，網(wǎng)絡(luò)設(shè)備的更新?lián)Q代需要數(shù)年時間，所以這些新技術(shù)只有在新建的數(shù)據(jù)中心網(wǎng)絡(luò)中才能有機會出現(xiàn)，能支持INT功能的網(wǎng)絡(luò)設(shè)備必然具有芯片自編程能力，這對網(wǎng)絡(luò)設(shè)備提出了更高要求。除了以上介紹的這三種可視化技術(shù)，還有微軟在2015年提出的Pingmesh技術(shù)，以及依然是微軟在2015年提出的Everflow技術(shù)，還有Netsight(具體采用的Openflow協(xié)議)、ATPG、Planck等等，這些都是這兩年出現(xiàn)的可視化技術(shù)，雖然沒有g(shù)RPC、INT影響力大，但技術(shù)也在不斷完善中，未來也不好說哪些技術(shù)一定能勝出，哪些技術(shù)會直接淘汰，去讓時間證明一切吧。