Service Telemetry數(shù)據(jù)采集方案白皮書 2022

1分布式存儲技術(shù)與產(chǎn)業(yè)分析報告ServiceTelemetry數(shù)據(jù)采集方案白皮書1分布式存儲技術(shù)與產(chǎn)業(yè)分析報告ServiceTelemetry數(shù)據(jù)采集方案白皮書開放數(shù)據(jù)中心標準推進委員會ServiceTelemetry數(shù)據(jù)采集方案白皮書版權(quán)聲明ODCC（開放數(shù)據(jù)中心委員會）發(fā)布的各項成對于未經(jīng)著作權(quán)人書面同意而實施的剽竊、復制、修IServiceTelemetry數(shù)據(jù)采集方案白皮書編制說明本報告在撰寫過程中得到了多家單位的大力支）：騰訊、百度、中國移動、美團、博通、華三、華為）：胡小媛、包貴新、秦鳳偉、杜海峰、何宗應(yīng)、晏思宇、楊揚、馮耀烽、孫ServiceTelemetry數(shù)據(jù)采集方案白皮書前言在云化和AI時代，數(shù)據(jù)中心網(wǎng)絡(luò)由數(shù)十萬級的交換機設(shè)備、百萬級的網(wǎng)卡和數(shù)千萬級網(wǎng)絡(luò)實例組成，并不斷在隨著業(yè)務(wù)動態(tài)變化，復雜性遠超以往。計算資源池化、存儲資源池化后產(chǎn)生的指數(shù)級數(shù)據(jù)流量增長給數(shù)據(jù)中心網(wǎng)絡(luò)的運營帶來了嚴峻挑戰(zhàn)。我們改變傳統(tǒng)網(wǎng)絡(luò)管理工作的思路，設(shè)計了面向應(yīng)用的ServiceTelemetry平臺，采用應(yīng)用看網(wǎng)絡(luò)的視角，基于大數(shù)據(jù)技術(shù)結(jié)合AI算法實現(xiàn)應(yīng)用流模型畫像，解決故障發(fā)現(xiàn)難、診斷難和界定難的問題，并提供應(yīng)用瓶頸識別，性能優(yōu)化、故障規(guī)避和預(yù)測等網(wǎng)絡(luò)服務(wù)能力。本文著重介紹ServiceTelemetry數(shù)據(jù)采集方案白皮書 I II III 1 1 1 3 3 3 4 4 5 6 6 7 8 8 9 9 10 10ServiceTelemetry數(shù)據(jù)采集方案白皮書 10 10 14VServiceTelemetry數(shù)據(jù)采集方案白皮書網(wǎng)絡(luò)遙測技術(shù)serviceTelemetry圖1傳統(tǒng)網(wǎng)絡(luò)遙測技術(shù)與ServiceTelemetry的對比圖為網(wǎng)管系統(tǒng)定制信息、并通過設(shè)備實時主動推送數(shù)據(jù)的技術(shù)。不同于傳統(tǒng)網(wǎng)絡(luò)測量技術(shù)采集數(shù)據(jù)以IP報文格式呈現(xiàn)給分析工具，網(wǎng)絡(luò)遙測技術(shù)通常使（二）面向應(yīng)用的網(wǎng)絡(luò)遙測技術(shù)（ServiceTelemetry）圖2基于ServiceTelemetry的業(yè)務(wù)監(jiān)控框架現(xiàn)了從單一的網(wǎng)絡(luò)質(zhì)量監(jiān)控到業(yè)務(wù)與網(wǎng)絡(luò)聯(lián)合監(jiān)控的轉(zhuǎn)變，同時實現(xiàn)了從設(shè)1ServiceTelemetry數(shù)據(jù)采集方案白皮書傳統(tǒng)的網(wǎng)絡(luò)運維視角只關(guān)注帶寬使用情況，丟包具體內(nèi)容和原因等指標，但這些指標對業(yè)務(wù)的性能產(chǎn)生多大的影響，無法有效的關(guān)聯(lián)。只有將網(wǎng)絡(luò)指標和應(yīng)用指標相互關(guān)聯(lián)，構(gòu)建出業(yè)務(wù)流的畫像的系統(tǒng)，才能精確度量出應(yīng)用的隨著應(yīng)用架構(gòu)逐漸向分布式發(fā)展，導致大量incast突發(fā)流量網(wǎng)絡(luò)上涌現(xiàn)，多種硬件卸載技術(shù)被廣泛應(yīng)用，更快更輕的網(wǎng)絡(luò)通信方式相繼涌現(xiàn)，這也進一步增大網(wǎng)絡(luò)吞吐壓力。同時存儲介質(zhì)的不斷升級，網(wǎng)絡(luò)IO時延問題進一步成為制約存儲性能提升的關(guān)鍵瓶頸問題，唯有準確查找出存儲長尾時大規(guī)模的網(wǎng)絡(luò)故障發(fā)現(xiàn)難，問題界定更難，比如網(wǎng)絡(luò)微突發(fā)抖動很常見并不易感知，而應(yīng)用對時延的抖動問題卻很敏感。需要分析瓶頸在應(yīng)用側(cè)還基于“以應(yīng)用為中心的網(wǎng)絡(luò)”理念，我們提出ServiceTele念，向業(yè)務(wù)提供高精度、更加豐滿和定制化的數(shù)據(jù)，幫助業(yè)務(wù)打開網(wǎng)絡(luò)的黑盒子，為未來向業(yè)務(wù)故障預(yù)測、應(yīng)用驅(qū)動網(wǎng)絡(luò)等愿景前進打下基礎(chǔ)。度量業(yè)務(wù)實例性能影響的關(guān)鍵指標：比如TPS\QPS\IOPS、IO抖動、長2應(yīng)用畫像功能是在ServiceTelemetry平臺實現(xiàn)業(yè)務(wù)的關(guān)鍵數(shù)據(jù)采集和多維度分析，輸出的分析報告，包括對業(yè)務(wù)流維度的端到端完成時間和在每個網(wǎng)絡(luò)節(jié)點的逐跳時延，比如TPS\QPS\IOPS，以及l(fā)atencyp99鍵指標的評估分析。只有將網(wǎng)絡(luò)指標和應(yīng)用指標映射關(guān)聯(lián)，構(gòu)建出業(yè)務(wù)流的應(yīng)用架構(gòu)分布式發(fā)展、多種硬件卸載技術(shù)廣泛應(yīng)用，對于應(yīng)用畫像精確度、數(shù)據(jù)處理能力等方面都提出了巨大挑戰(zhàn)，沒有辦法采集并分析全部業(yè)務(wù)流量，必須更加有的放矢地選取具體關(guān)鍵流程報文進行染色、達到精準度量而不額外增加網(wǎng)絡(luò)通信開銷。針對這一問題，ServiceTelemetry實現(xiàn)了的關(guān)鍵業(yè)務(wù)流識別方法，此類關(guān)鍵業(yè)務(wù)流以消息較小且內(nèi)容完整為主要特征，通常包括業(yè)務(wù)實例的類型，任務(wù)消息大小和種類，任務(wù)開始和完成標識等信息，一般為控制報文，這類報文通常與數(shù)據(jù)傳輸?shù)牧魇褂孟嗤逆溄?，也就有相同的網(wǎng)絡(luò)轉(zhuǎn)發(fā)路徑，因此只需對此類關(guān)鍵業(yè)務(wù)流進行染色識別即可。業(yè)務(wù)在對數(shù)據(jù)結(jié)構(gòu)定義時，在IP報文四層頭后面插入特定報文頭標記報文），3ServiceTelemetry數(shù)據(jù)采集方案白皮書業(yè)務(wù)端染色完成后，進入接入層網(wǎng)絡(luò)設(shè)備，設(shè)備在轉(zhuǎn)發(fā)芯片內(nèi)建立一個業(yè)務(wù)實例表Service_Table，以業(yè)務(wù)實例報文源IP、目號（Service_Seq）唯一標識一個業(yè)務(wù)實例，這個表里同時還記錄該實例的時間戳、業(yè)務(wù)實例類型、業(yè)務(wù)實例編號、業(yè)務(wù)實例傳輸大小等信息；并Service_Table中不存在時，則創(chuàng)建一條實例表項；如該業(yè)務(wù)實例編號（Service_Seq）在Service_Table中已存在，判斷業(yè)務(wù)實例類型，并根據(jù)Service類型更新Service_Table中該實例的內(nèi)容；在識別出一個業(yè)務(wù)實例的完成報文（Service_Resp更新時間戳，并將Service該業(yè)務(wù)實例表項封裝為ServiceTelemetrystream上送分析平臺，同時網(wǎng)絡(luò)設(shè)備本地刪除該條表項記錄；分析平臺實時進行數(shù)據(jù)的分析和統(tǒng)計，比如針對不同消息大小的業(yè)務(wù)實例，不同時段的業(yè)務(wù)實例，進行測量比較，評估業(yè)務(wù)的健康狀態(tài)。還可以深入進行多維度的分析，比如業(yè)務(wù)實例時延分布情當ServiceTelemetry平臺分析發(fā)現(xiàn)業(yè)務(wù)性能的一些異常情況，比如業(yè)務(wù)實例IO長尾時延數(shù)據(jù)對比典型值的波動超出閾值，則可以針對性觸發(fā)對以進一步對網(wǎng)絡(luò)進行分析，找出問題網(wǎng)絡(luò)設(shè)備或者鏈路。具體過程如下：ServiceTelemetry分析染色并打時間戳，在逐跳的網(wǎng)絡(luò)設(shè)備上對探針報文打上入、出時間戳，入、出網(wǎng)絡(luò)端口信息，網(wǎng)絡(luò)設(shè)備ID，網(wǎng)絡(luò)設(shè)備質(zhì)量狀態(tài)等信息，目的服務(wù)器收到業(yè)務(wù)探針報文，打上時間戳并復制封裝上送ServiceTelemetry分析器，同時發(fā)送業(yè)務(wù)響應(yīng)報文，染色并打時間戳，以完成對回程報文轉(zhuǎn)發(fā)路徑的采集；ServiceTelemetry分析器可以根據(jù)業(yè)務(wù)報文的雙向轉(zhuǎn)發(fā)路徑，根據(jù)時間戳信息得出該雙向轉(zhuǎn)發(fā)路徑各自的網(wǎng)絡(luò)時延，從而評估該業(yè)務(wù)完整轉(zhuǎn)發(fā)路4ServiceTelemetry數(shù)據(jù)采集方案白皮書屬性含義數(shù)據(jù)類型數(shù)據(jù)長度DestinationIP業(yè)務(wù)實例響應(yīng)端IP地址4B業(yè)務(wù)實例發(fā)起端IP地址4BServiceSequence業(yè)務(wù)實例序列號2BServiceType業(yè)務(wù)實例類型ServiceSize業(yè)務(wù)實例大小Timestamp業(yè)務(wù)發(fā)起時間double4BTimestampUpdate業(yè)務(wù)最近更新時間double4B屬性U含義數(shù)據(jù)類型數(shù)據(jù)長度網(wǎng)絡(luò)設(shè)備ID4ByteCongestion擁塞標志位5bitDropPkt業(yè)務(wù)實例序列號1Byte報文的TTL值1ByteRxTimestamp入接口時間戳double2ByteTxTimestamp出接口時間戳double2ByteIngressPort入接口2Byte5ServiceTelemetry數(shù)據(jù)采集方案白皮書EgressPort出接口2Byte屬性含義數(shù)據(jù)類型數(shù)據(jù)長度網(wǎng)絡(luò)設(shè)備ID1ByteCollectoraddress采集器IP地址4ByteDestinationport采集器端口號2ByteSourceaddress網(wǎng)絡(luò)設(shè)備上送源IP4ByteSourceport網(wǎng)絡(luò)設(shè)備上送源端口2Byte屬性含義數(shù)據(jù)類型數(shù)據(jù)長度DestinationIP業(yè)務(wù)實例響應(yīng)端IP地址4Byte業(yè)務(wù)實例發(fā)起端IP地址4ByteServiceSequence業(yè)務(wù)實例序列號2ByteErrorType異常類型1Byte業(yè)務(wù)流量微突發(fā)（Microburst）是數(shù)據(jù)中心網(wǎng)絡(luò)中一種常見的現(xiàn)象，是端口在非常短的時間（毫秒級別）內(nèi)收到非常多的突發(fā)數(shù)據(jù)，典型的微突發(fā)的持續(xù)時間通常在1～100毫秒之間，以至于瞬時突發(fā)速率達到平均速率的數(shù)十倍、數(shù)百倍，甚至超過端口帶寬的現(xiàn)象。微突發(fā)流量會降低數(shù)據(jù)中心業(yè)6ServiceTelemetry數(shù)據(jù)采集方案白皮書務(wù)的性能。微突發(fā)流量會導致網(wǎng)絡(luò)丟包，影響到業(yè)務(wù)的性能。但是傳統(tǒng)的網(wǎng)度也只能做到秒級，而要發(fā)現(xiàn)網(wǎng)絡(luò)環(huán)境中的微突發(fā)現(xiàn)象，通常需要ms級別的高精度監(jiān)控。如圖3.1，實際的微突發(fā)流量是綠色曲線，監(jiān)控平臺往往讀圖3數(shù)據(jù)中心流量業(yè)務(wù)微突發(fā)場景業(yè)務(wù)流量存在波動：很多通用的業(yè)務(wù)模型下，用戶的請求和服務(wù)器的響應(yīng)是離散出現(xiàn)的，導致業(yè)務(wù)流量是間歇性的，不穩(wěn)定。同時對時延和帶寬敏傳統(tǒng)的TCP發(fā)包原則：通過慢啟動和擁塞避免機制，盡快將數(shù)據(jù)包發(fā)送出去。慢啟動使得發(fā)送速率不會快速上升。當吞吐量達到上限后，TCP滑動窗口減半，速率迅速下降，導致會話流量呈鋸齒狀，具有突發(fā)性。TCP總是期望把發(fā)送窗口中的數(shù)據(jù)盡快發(fā)送完，所以會在等待TCP的報文到達確認（ACK）到來后，通過滑動窗口機制再繼續(xù)發(fā)送數(shù)據(jù)，如此循環(huán)，使得發(fā)包流量的入端口總帶寬和超過出端口的總帶寬。廣泛存在在數(shù)據(jù)中心的分布式應(yīng)用，會存在高帶寬端口向低帶寬的出端口轉(zhuǎn)發(fā)流量、多個入端口向一7ServiceTelemetry數(shù)據(jù)采集方案白皮書個出端口轉(zhuǎn)發(fā)流量。以及網(wǎng)絡(luò)設(shè)備上不適當?shù)腝oS參數(shù)配置，如隊列調(diào)度和當微突發(fā)流量的瞬時速率超過網(wǎng)絡(luò)設(shè)備的轉(zhuǎn)發(fā)能力時，網(wǎng)絡(luò)設(shè)備會將突發(fā)的數(shù)據(jù)進行緩存以便稍后發(fā)送。但是在數(shù)據(jù)中心網(wǎng)絡(luò)里大多采用小緩存的盒式網(wǎng)絡(luò)設(shè)備，一旦緩存溢出，會導致出現(xiàn)大量丟包的情況，影響到業(yè)務(wù)性4．微突發(fā)監(jiān)控的實現(xiàn)傳統(tǒng)監(jiān)控微突發(fā)的方案是針對所有的流量進行實時的監(jiān)控和統(tǒng)計，利用流表來記錄五元組并持續(xù)計數(shù)，但受限于網(wǎng)絡(luò)設(shè)備芯片流表容量，無法做到全量監(jiān)控，同時因為突發(fā)是微秒級別，并瞬間存在，控制面無法及時捕獲。更重要的是，網(wǎng)絡(luò)運營團隊對微突發(fā)和丟包問題不僅需要精確發(fā)生的時間，更需要準確知道發(fā)生導致微突發(fā)現(xiàn)象具體報文的內(nèi)容以及關(guān)聯(lián)的具體業(yè)務(wù)。ServiceTelemetry平臺的微突發(fā)監(jiān)控重點針對這幾方面的難點進行優(yōu)化，交換機的MMU上設(shè)定微突發(fā)開始水線和微突發(fā)停止水線（水線代表在一個時間窗口內(nèi)的緩存計數(shù)），當交換芯片收到的報文就給后續(xù)報文都打上微突發(fā)標記，當收到的報文超過MMU丟棄水線在交換機出方向匹配到microburst標記位時，從報文中抽取五元組信息并以精確匹配方式查找該設(shè)備的微突發(fā)五元組流表，如果沒有命中則意味這這是一條受本微突發(fā)影響的新流因而在該表中插入一條新條目，包括五元組，時間戳、入口端口信息、隊列信息、出口隊列緩存的使用率等，設(shè)備啟8ServiceTelemetry數(shù)據(jù)采集方案白皮書同時設(shè)備啟動啟用周期性定時器，當設(shè)備長時間不再檢測到該流存在擁塞或者報文緩存回落到微突發(fā)結(jié)束水線，則認為擁塞現(xiàn)象已經(jīng)消失，發(fā)送最5．微突發(fā)數(shù)據(jù)分析所有微突發(fā)流上送到ServiceTelemetry后，以上送時間窗口和單臺網(wǎng)絡(luò)設(shè)備為一個獨立的分析單元，統(tǒng)計每個分析單元內(nèi)的所有流微突發(fā)的持續(xù)屬性含義數(shù)據(jù)類型數(shù)據(jù)長度CPUTimer基于流的微突發(fā)信息上送Collector1BytesdropCn-byte微突發(fā)導致丟包數(shù)字節(jié)數(shù)2BytesdropCn-pkt微突發(fā)導致丟包數(shù)2BytesDropthreshold微突發(fā)丟包水線2BytesFinishthreshold微突發(fā)buffer結(jié)束水線2BytesFinishTimer多少時間沒有收到微突發(fā)采樣報文，判斷為微突發(fā)結(jié)束4Bytes9ServiceTelemetry數(shù)據(jù)采集方案白皮書MicroburstCnt-byte微突發(fā)的報文字節(jié)數(shù)2BytesMicroburstCnt-pkt微突發(fā)的報文數(shù)2BytesSample按多少進行采樣2BytesStartthreshold微突發(fā)buffer觸發(fā)水線2Bytes圖4ServiceTelemetry的系統(tǒng)框架（二）下發(fā)和采集規(guī)范用gRPCDial-in模式，設(shè)備作為gRPC服務(wù)器，采集器作為由采集器主動向設(shè)備發(fā)起gRPC連接并訂閱需要采集的數(shù)據(jù)信息。ServiceTelemetry數(shù)據(jù)采集方案白皮書這里與Telemetry的下發(fā)模式一致，采用gnmi的標準set接口進行下ServiceTelemetry數(shù)據(jù)采集方案白皮書ServiceTelemetry數(shù)據(jù)采集方案白皮書下發(fā)配置，path需要指定key值，且path路徑為leaf的上一層節(jié)點關(guān)于update中的val字段，TypedValue這里支持很多類型的數(shù)據(jù)，這ServiceTelemetry數(shù)據(jù)采集方案白皮書ServiceTelemetryStream可以部署在網(wǎng)絡(luò)的接入層、匯聚層、核心層，是指通過對業(yè)務(wù)報文的處理對業(yè)務(wù)實例質(zhì)量進行測量、統(tǒng)計和分析，并將統(tǒng)計結(jié)果上報給采集器，合并處理后存入ServiceTelemetry分析平臺。ServiceTelemetryStream可以將業(yè)務(wù)實例類型、業(yè)務(wù)實例大小，完成時隊列信息、以及每一跳的耗費的時延的時間戳信息封裝成標準IP報文。封屬性含義數(shù)據(jù)類型數(shù)據(jù)長度VersionIPFIX版本2ByteLength采集器IP地址2ByteExportTimeIPFIX消息頭離開Exporter的時間，表示自1970年1月1日起的UNIX