一、 概述

基于傳統的SNMP網絡監控系統專為傳統實現而設計，當今高密度平臺的擴展性較差，而且可擴展性非常有限，而SNMP是基于查詢的模式，網管系統通過定期發送snmp 查詢消息，獲取網絡設備的接口統計、CPU使用率、內線占用率等等；由于是定時查詢，一般情況下我們都是配置5分鐘，即300秒；而在網絡中會存在某一個時刻就會有突發數據，可是這突發流量仍然會造成網絡接口丟包。但在基于SNMP查詢時經常又感知不到突發的存在，所有從SNMP獲取的數據看來流量是非常穩定的，但是客戶抱怨網絡很差。

綜上所述，SNMP在現如今的網絡環境下，的確遇到了瓶頸。尤其是網絡規模日益擴大的今天，怎么辦？ 我們能不能換個角度，把傳統的從監控系統到網絡設備”拉“數據的方法，變為網絡設備主動向監控系統”推“數據的方法？

二、 Streaming Telemetry技術

流式遙測是(StreamTelemetry)一種用于網絡監控的新方法，它就是實現了上述“推”數據的方法,網絡管理員可以通過訂閱的方式將特定數據項（標準化）從網絡設備發往數據收集器.

事實上Stream Telemetry并不是新發明，sFlow和NetFlow等早已實現了網絡流量的采樣和推送，下面介紹目前三種主流的流式遙測技術。

1.sFlow

行業標準sFlow是SNMP的流式遙測替代方案，在過去近20年中已經被供應商迅速采用。

sFlow是嵌入在交換機和路由器中的采樣技術，數據包采樣是基于硬件的，由交換ASIC執行，實現線速性能，它使sFlow成為一種可擴展的技術，能夠以高達10 GBps的速度監控鏈路，。完整的一套sFlow系統由sflow Sample、sFlow Agent和sFlow Collector組成。

sFlow Agent是一個軟件進程，作為設備中網絡管理軟件的一部分運行（參見圖2）。 它將端口上的計數統計和采樣得到的數據封裝為sFlow數據報通過網絡發送到sFlow收集器。 報文的采樣通常由交換/路由ASIC執行，它能提供以線速的方式提供采樣，以此同時它還可以記錄相關聯的轉發/路由表條目的狀態。 sFlow Agent執行的處理非常少。 它只是將數據打包到sFlow數據報中，這些數據報立即在網絡上發送。 立即轉發數據可最大限度地減少與sFlow Agent相關的內存和CPU要求。

圖3顯示了sFlow系統的基本元素。整個網絡中的sFlow代理不斷向中央sFlow收集器發送sFlow數據報流，在中央sFlow收集器中對它們進行分析，以生成豐富，實時，網絡范圍的流量視圖。高速，路由和交換網絡的sFlow監控具有以下特性：

（1）準確 因為采樣非常簡單，可以在硬件中執行，所以它以線速運行。此外，sFlow系統的設計使得可以確定任何測量的精度。其他交通流量測量技術在重負載下發生折疊，導致難以量化的錯誤。

（2）詳細的完整數據包標頭和交換/路由信息允許詳細分析L2-L7流量。  

（3）可擴展 sFlow系統可以在其可監控的網絡的大小和速度上進行擴展。 sFlow能夠監控10Gbps，100Gbps及更高速率的網絡。單個sFlow Collector可以監控數千個設備。

（4）低成本 sFlow Agent實現起來非常簡單，并且可以為交換機或路由器增加可忽略的成本。

（5）及時 sFlow Collector始終在整個網絡中擁有最新的流量視圖。如果需要交通數據來提供實時控制，及時的信息尤為重要。例如，管理服務質量或抵御拒絕服務攻擊。

目前基于sFlow已成為行業的基本標準，其由RFC3176制訂規范，目前所有主流交換機廠商的設備基本上都支持sflow，由于sFlow是行業標準，故sFlow Collector和sFlow Analyzers可由專門的廠商提供；目前盛科的芯片已實現sFlow采樣技術，芯片可基于Port/Vlan/Flow將報文采樣送到CPU的sFlow Agent處理，然后組裝報文送到sFlow Collector。

2.NetFlow/NetStream/IpFix等

前述的sFlow是一種純數據包采樣技術，即每一個被采樣的X包的長度被記錄下來，而大部分的包則被丟棄，只留下樣本被傳送給采集器，所以它不可能獲得每臺主機流量100%的準確值；而NetFlow（或NetStream、IpFix（NetFlow v9））不同，它用來跟蹤每個開啟NetFlow功能接口上的所有進入會話的技術。比如它根據7個關鍵標準分析數據包，如果兩個包在所有7個判斷標準上都匹配的話，就把它們歸類為相同的流量或會話。一旦會話結束或被匯總，就被傳送給采集器，所以如果NetFlow配置恰當并且硬件沒有過載的話，這種技術可以以接近100%的準確性來描述誰經過設備進行通信。   

由于NetFlow產生的數據包數量會非常巨大，由于需要100%的會話流量進行處理同一會話做比較，記錄和緩存，所以在采集器的負擔非常的重，采集器可能會變得不堪重負，早期，無論NetFlow還是NetStream是一種軟件技術，報文的采樣、緩存和數據導出等都是在CPU中完成的，故只有在路由器設備才能看到有相應的應用。

近年來，由于交換技術的發展，特別是對網絡監控越來越重視，交換芯片內部開始集成NetFlow的采集器，以盛科芯片為例，盛科的IpFix技術在交換機內部硬件完成Ipfix會話的學習、會話記錄、會話更新、觸發導出等功能，最大限度的降低CPU的負擔。

3.openConfig

OpenConfig是近年來由Google提出（谷歌推動的Stratum項目），希望提供一個中立于設備廠商的標準 API等，有別于NetConfig是由網絡設備廠商推動的，內耗太大，各個設備廠商都希望在軟件定義網絡的時代繼續保持硬件設備的重要性，并且能夠體現自己公司產品的差異化優勢，所以一經推出得到了各互聯網提供商的積極響應，目前AT&T，British Telecom，Facebook，Apple，Microsoft 等互聯網服務提供商加入了 OpenConfig 工作組，目前國內的騰訊、百度和阿里等互聯網服務提供商也已經加入了 OpenConfig 工作組，網絡設備商Cisco、Juniper也在其設備中增加對OpenConfig的支持。

       OpenConfig也不是一個全新的技術，它 沿用了 Netconf 的協議框架，但是它不太關注底層的數據傳輸，而是更關注上層的數據表達和數據建模。這意味著：不管是 A 廠還是 B 廠，所有的數據都必須符合 OpenConfig YANG Model，并且 Key-Value 都必須是 OpenConfig 所規定的標準格式，基于YANG Model/gRPC的OpenConfig網絡管理系統包括的網絡配置管理和流式遙測(Streaming Telemetry)，流式遙測（Streaming Telemetry）作為是網絡監控是其重要的組成部分，Telemetry技術的采樣數據源來自轉發面、控制面和管理面的數據源，數據按照YANG模型描述的結構進行組織，利用GPB格式編碼，并通過GRPC協議將數據上送至采集器和分析器進行分析處理。

    目前OpenConfig官方定義了大量標準YANG模型，用于統一設備管理，期望一統天下，解決不同設備廠商間兼容的問題。

 而其中定義的Openonfig-telemetry.yang 是描述網絡設備telemetry的參數信息，包括：

（1）配置采樣傳感器組（sensor-group），包括傳感器路徑（sensor-path）和過濾條件，其sensor-path對應于需要采樣的YANG Model所在的路徑;

（2）配置上送目的組（estination-group）包括配置上送目標采集器的IP地址、端口號、上送目標傳感器的協議和加密方式;

（3）配置訂閱（subscription）參數包含配置關聯采樣任務組、采樣周期，關聯上送目標，觸發采樣、冗余抑制以及心跳間隔.

三、流式遙測優勢

對比傳統SNMP/CLI，Telemetry 具有以下優勢：

1.Telemetry 采用推模式推送數據，降低設備壓力

傳統SNMP/CLI“一問一答”拉模式采集數據；

Telemetry 采用“一次網管訂閱，多次響應“推模式采集數據，由于設備以周期性推送的方式向采集器主動推送數據，而不是被動的等待采集器定時查詢，避免查詢請求在網絡傳輸中的延遲和大量查詢請求對網絡和設備帶來的壓力，提升監控性能

2.實現更實時更精確的監控,避免網絡延時導致數據不準確;

在設備上線注冊的時候，SNMP模式下，設備就只能等待網管系統的定期輪循掃描；而Telemetry模式下，設備啟動后馬上上報注冊，讓監控系統即刻發現自己，保證監控系統的及時性和不間斷性；

在視頻出現卡頓時，傳統模式下可能需要查詢T1時刻CPU信息以滿足行為判斷；但由于網絡卡頓得到是是T1+3時刻的數據網絡出現失真；而在Telemetry 由于提前訂閱了CPU信息，網絡延時不影響，數據不會出現失真;

雖然傳統的監控模式也可以通過SNMP TRAP或SysLog等方式主控上報數據，但定時上報的時間一般為分鐘級或秒級；而Telemetry可做到亞秒級或實時；

3.Telemetry可以訂閱大量的監控節點，彌補傳統網絡監控方式的不同；

傳統方式需要查詢N臺設備，做N次查詢同時采集M種數據，則一臺網管設備需要N*N*M次查詢，并返回N*N*M次結果

而Telemetry 的設備都只需要提前訂閱，各種設備實時上報，無需人工操作；

4.數據結構不同，傳統的SNMP采用MIB定義結構；而Telemetry 采用YANG模型定義結構；

四、廠商支持情況

1.Cisco

Cisco Model-driven Telemetry (MDT)技術就是來實現基于YANG Model的Telemetry,目前Cisco支持以下的YANGmodels來配置支持MDT：nopenconfig-telemetry.yang提供OpenConfig的配置；nCisco-IOS-XR-telemetry-model-driven-cfg.yang通過NETCONF配置MDT相關的配置nCisco-IOS-XR-telemetry-model-driven-oper.yang讀取關于MDT的信息.

2.SONIC

由微軟主導的SONIC系統的Telemetry參考OpenConfig的架構定義，數據源主要為為兩部分：以CPU子系統相關的監控數據由SONIC系統軟件采集，消息封裝和消息發布；以芯片相關的監控數據由SAI軟件進行數據采集、消息封裝和發布，但就目前進展來看，消息發布的格式并沒有完全細化，還有待進一步的定義。

3. Stratum項目

由Google主導的Stratum項目完全拋棄了SNMP/CLI管理模式，采用全新的基于YangModel的OpenConfig模型，目前整個項目還處于開發階段，只有項目組成員可以訪問其代碼。

五、 總結

無論是sFlow、NetFlow、NetStream或者是IPFix都是實現了主動向采集器上送設備數據信息，實現了推模式（Push Mode），但他們推送的都是最原始的數據采樣信息，數據以IP報文格式呈現給分析工具，而非用戶期望的規范化數據模型，所以預計未來不久，基于Yang的OpenConfig的數據模型將成為新一代數據中心網絡運維管理系統的主流選擇，無論是芯片廠商還是設備廠商，數據信息采集后導出的方式采用標準化和規范化數據模型（如YANG Mode）勢在必行。