03-數(shù)據(jù)為王,高歌猛進(jìn)的Telemetry

4.3.1據(jù)為王，高歌猛進(jìn)的Telemetry第二章中，我們提到汽車自動(dòng)駕駛對(duì)網(wǎng)絡(luò)運(yùn)維的啟發(fā)，業(yè)界針對(duì)自動(dòng)駕駛汽車定義了三層系統(tǒng)架構(gòu)，包括Sensor、分析+控制和云平臺(tái)。底層的Sensor作為數(shù)據(jù)的來(lái)源，通過(guò)雷達(dá)、微波、激光等多種類型的傳感器，精準(zhǔn)地感知周邊路況信息，基于這些信息，汽車可以對(duì)前方的急剎車、橫穿馬路的行人、上下坡等各種情況做出精確的反應(yīng)。那么對(duì)于電信行業(yè)的自動(dòng)駕駛，在其三層智能的系統(tǒng)架構(gòu)中，同樣也需要在物理網(wǎng)絡(luò)層構(gòu)建一個(gè)能實(shí)時(shí)感知態(tài)勢(shì)的"Sensor”，將面向網(wǎng)絡(luò)和業(yè)務(wù)級(jí)應(yīng)用的真實(shí)數(shù)據(jù)實(shí)時(shí)上報(bào)，為上層預(yù)測(cè)性運(yùn)維和主動(dòng)閉環(huán)優(yōu)化提供數(shù)據(jù)基礎(chǔ)。那么對(duì)于自動(dòng)駕駛網(wǎng)絡(luò)，什么樣的"Sensor”更合適？先來(lái)看一個(gè)例子，2018年世界杯，運(yùn)營(yíng)商A的IPTV視頻直播頻發(fā)卡頓和模糊。眾所周知，用戶對(duì)直播視頻的流暢度要求極高，往往幾秒鐘的卡頓就會(huì)影響到用戶對(duì)直播觀看的體驗(yàn)，重復(fù)發(fā)生必然會(huì)影響其IPTV的品牌影響力，導(dǎo)致用戶流失。那么作為直播視頻的運(yùn)營(yíng)商，應(yīng)該如何對(duì)秒級(jí)卡頓問(wèn)題進(jìn)行感知分析，自動(dòng)調(diào)整網(wǎng)絡(luò)配置，主動(dòng)閉環(huán)優(yōu)化，保證用戶觀看體驗(yàn)?zāi)?？?duì)秒級(jí)卡頓的感知，首先必須獲取到秒級(jí)/亞秒級(jí)的網(wǎng)絡(luò)質(zhì)量數(shù)據(jù)，做到實(shí)時(shí)的大數(shù)據(jù)上報(bào)。然而我們知道，傳統(tǒng)網(wǎng)絡(luò)運(yùn)維模式以設(shè)備為中心，常用的數(shù)據(jù)采集方式，例如SNMP，采集周期為5分鐘，過(guò)大的采集周期，會(huì)導(dǎo)致細(xì)節(jié)信息丟失，無(wú)法支撐秒級(jí)卡頓的自動(dòng)優(yōu)化閉環(huán)。例如圖1,正常的接口帶寬變化是如下的紅色線條，但SNMP定期查詢采集到的卻是風(fēng)平浪靜的綠色線條，無(wú)法發(fā)現(xiàn)圓圈標(biāo)識(shí)的流量異常下降。H：=J圖1H：=J圖1接口帶寬監(jiān)控曲線那么采集周期可以縮短，從而實(shí)現(xiàn)實(shí)時(shí)采集嗎？傳統(tǒng)SNMP是拉模式(PullMode)的"請(qǐng)求-回答”式交互，每次采集數(shù)據(jù)都需要網(wǎng)管發(fā)起查詢請(qǐng)求，設(shè)備解析請(qǐng)求后再響應(yīng)上報(bào)數(shù)據(jù)。就像按壓式抽水泵一樣，壓一下出一點(diǎn)水。采集效率低，無(wú)法做到實(shí)時(shí)采集。

圖2圖2按壓式抽水泵而且數(shù)據(jù)模型的兼容性也差，例如SNMP基于MIB數(shù)據(jù)模型，由各廠商自定義。也就是說(shuō)如果網(wǎng)管系統(tǒng)要管理其他廠商的設(shè)備，可能需要花很大力氣去學(xué)習(xí)該廠商的MIB模型。網(wǎng)絡(luò)自動(dòng)駕駛需要更標(biāo)準(zhǔn)的數(shù)據(jù)模型，提升運(yùn)維效率，所以傳統(tǒng)SNMP不適合做自動(dòng)駕駛網(wǎng)絡(luò)的"Sensor”。從上面的舉例和傳統(tǒng)采集方式的問(wèn)題中，我們可以窺探出自動(dòng)駕駛網(wǎng)絡(luò)"Sensor”的選擇標(biāo)準(zhǔn)：基于標(biāo)準(zhǔn)的數(shù)據(jù)模型，實(shí)時(shí)大數(shù)據(jù)上報(bào)，實(shí)時(shí)感知，洞察業(yè)務(wù)細(xì)節(jié)。Telemetry技術(shù)應(yīng)運(yùn)而生在前面的章節(jié)里，我們講過(guò)YANG，基于這個(gè)不斷完善的標(biāo)準(zhǔn)數(shù)據(jù)模型，和Google提出的gRPC傳輸協(xié)議，Telemetry技術(shù)應(yīng)運(yùn)而生。QpenCflnfiflfiEff仁也女心miItMtrcwf:5**KT.FLwslil〕CC^L伽罰心！?刑1T■-Bellq. KDfLII OT?gw2005年，Google提出gRPC（Telemetry使用的傳輸協(xié)議）供內(nèi)部使用，至2015年，Google公開(kāi)gRPC,主導(dǎo)成立了OpenConfig組織，包含領(lǐng)先的互聯(lián)網(wǎng)廠商和運(yùn)營(yíng)商，例如BT,AT&T,SKT,Telefonica,ORACLE,MicrosoftQpenCflnfiflfiEff仁也女心miItMtrcwf:5**KT.FLwslil〕CC^L伽罰心！?刑1T■-Bellq. KDfLII OT?gw■Google主導(dǎo)！:K立0penConfig^gfR-OpenConhg^YANG模里-ItlF發(fā)布YANG欄型 Nowj I?Googlet根出#RPC ?Telem翩ry標(biāo)推進(jìn)一步完善?基與1」口=＞何.*擊式上送機(jī)制圖3Telemetry發(fā)展歷史

Telemetry是一項(xiàng)遠(yuǎn)程的從物理設(shè)備或虛擬設(shè)備上高速采集數(shù)據(jù)的技術(shù)。設(shè)備通過(guò)推模式（PushMode）周期性的主動(dòng)向采集器上送設(shè)備的接口流量統(tǒng)計(jì)、CPU或內(nèi)存數(shù)據(jù)等信息，而不是被動(dòng)的等待采集器定時(shí)查詢。避免查詢請(qǐng)求在網(wǎng)絡(luò)傳輸中的延遲和大量查詢請(qǐng)求對(duì)網(wǎng)絡(luò)和設(shè)備帶來(lái)的壓力，提升監(jiān)控性能。相對(duì)傳統(tǒng)拉模式（PullMode）的一問(wèn)一答式交互，提供了更實(shí)時(shí)更高速的數(shù)據(jù)采集能力。來(lái)看看推模式是怎么樣的？箔求CPU占用率③訂閱CPU占用率.碘1秒京嗽解析請(qǐng)求瞄CPUS用率iijiS^CPU占用率（幻懂收CPU占用率口； R浦柬CPU占用率：n）■ 撞收CPL」占用擊問(wèn) 1-T-Simin接咆CPUL亍用率J§4fcCPU：7.i|l^（2）接iftCPU占用筆（為接收CPU占用率｛n） ■闡培設(shè)窗網(wǎng)建設(shè)督EMS/NMST=ls傳驗(yàn)SNMPTiclcimetry圖4傳統(tǒng)的拉模式和Telemetry推模式對(duì)比（T：采集周期）傳統(tǒng)拉模式（例如SNMP）的查詢與設(shè)備之間是一問(wèn)一答的交互。每次下發(fā)查詢請(qǐng)求，設(shè)備都需要解析請(qǐng)求報(bào)文，即n次查詢請(qǐng)求、n次解析請(qǐng)求。而Telemetry的推模式，它只需要1次訂閱請(qǐng)求和1次解析請(qǐng)求，就可以按照訂閱指定周期持續(xù)推送數(shù)據(jù)給網(wǎng)管。采用推模式就可以做到實(shí)時(shí)采集了嗎？答案是否定的，Telemetry是一個(gè)特性，需要一系列技術(shù)的配合。Telemetry技術(shù)的采樣數(shù)據(jù)源來(lái)自網(wǎng)絡(luò)設(shè)備，數(shù)據(jù)按照通用的結(jié)構(gòu)化數(shù)據(jù)模型YANG進(jìn)行組織，利用GPB極簡(jiǎn)格式編碼，并通過(guò)gRPC或UDP協(xié)議將數(shù)據(jù)快速上送至采集器，供分析器進(jìn)行分析處理。圖5Telemetry框架這樣我們拿訂餐比喻數(shù)據(jù)采集，介紹以上技術(shù)的優(yōu)勢(shì)，理解下Telemetry與傳統(tǒng)采集方式的差異，為什么可以做到實(shí)時(shí)采集。

有位NCE太太獨(dú)自居住，不喜愛(ài)做飯，經(jīng)常需要訂餐?！谷战袀鹘y(tǒng)的SNMP餐廳是怎么訂餐的？首先他們的MIB菜單上的字是本地化的，需要翻譯學(xué)習(xí)后才能看懂（數(shù)據(jù)模型自定義，需要定制適配），而下單的過(guò)程是這樣的：Hello,請(qǐng)尊送T■兩紅秘曙蜀好㈤,f西紅柿雞真WCF西紅牡妙耙軍愉好店酣誤拾TNCEA ［拄程式一間二客變質(zhì)）WCF請(qǐng)紿我送一個(gè)言保蹲丁.好的.f■白保雞丁.個(gè)M保迪丁械H后朗我我了MCI太太.為什么不能一起做好送過(guò)來(lái)呢，因?yàn)镾NMP餐廳后廚的人力太少（設(shè)備硬件能力和管道傳輸能力弱），訂單太多會(huì)處理不過(guò)來(lái)，所以一次只能訂一個(gè)菜，送到了再訂下一個(gè)。這樣一頓飯吃下來(lái)是不是覺(jué)著很累，長(zhǎng)期訂飯的體驗(yàn)就更差了。那么Telemetry餐廳的體驗(yàn)是怎樣的？Telemetry餐廳使用的YANG菜單是全球通用的文字（通用的結(jié)構(gòu)化數(shù)據(jù)模型），NCE太太可以很快識(shí)別。Hello.請(qǐng)站我送一^紅柿炒雞鼠f昌保雞丁。每天定^配送.為期一個(gè)月，（推模式的訂閱式采集）好的?！惨淮谓馕觯?*冬Telemetry餐廳的后廚人力物力充分，并采用GPB方式快速烹飪（極簡(jiǎn)編碼格式），先進(jìn)的gRPC/UDP快遞配送系統(tǒng)（快速傳輸協(xié)議）。從此，NCE太太會(huì)源源不斷的收到她的訂餐。

利用Telemetry技術(shù)，智能運(yùn)維系統(tǒng)可以實(shí)時(shí)收集到大量的設(shè)備數(shù)據(jù)，將數(shù)據(jù)交給分析系統(tǒng)進(jìn)行綜合分析、決策后，將決策結(jié)果發(fā)送給控制器，由控制器調(diào)整設(shè)備的配置，然后又可以幾乎實(shí)時(shí)的收到調(diào)整后設(shè)備的狀態(tài)反饋，整個(gè)流程形成閉環(huán)。智能運(yùn)唯系統(tǒng)圖6Telemetry在智能運(yùn)維系統(tǒng)中的應(yīng)用智能運(yùn)維系統(tǒng)與各設(shè)備建立gRPC通道，在設(shè)備上配置Telemetry訂閱。各設(shè)備通過(guò)gRPC通道將訂閱數(shù)據(jù)上報(bào)給采集器。采集器接收、存儲(chǔ)、加工處理各設(shè)備上報(bào)的數(shù)據(jù)。分析器基于大數(shù)據(jù)分析系統(tǒng)進(jìn)行分析?？刂破飨掳l(fā)調(diào)優(yōu)指令對(duì)網(wǎng)絡(luò)進(jìn)行調(diào)優(yōu)。調(diào)優(yōu)指令下發(fā)生效后，新的采