《開放數據中心委員會：Service Telemetry數據采集方案白皮書（2022）（25頁）.pdf》由會員分享，可在線閱讀，更多相關《開放數據中心委員會：Service Telemetry數據采集方案白皮書（2022）（25頁）.pdf（25頁珍藏版）》請在三個皮匠報告上搜索。

1、1ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009分布式存儲技術與產業分析報告分布式存儲技術與產業分析報告編號 ODCC-2022-03009ServiceTelemetry 數據采集方案白皮書開放數據中心標準推進委員會開放數據中心標準推進委員會2022-09 發布發布IServiceTelemetry 數據采集方案白皮書ODCC-2022-03009版權聲明版權聲明ODCC（開放數據中心委員會）發布的各項成果，受著作權法保護，編制單位共同享有著作權。轉載、摘編或利用其它方式使用 ODCC成果中的文字或者觀點的，應注明來源：“開放數據中心委員會 ODCC”。對

2、于未經著作權人書面同意而實施的剽竊、復制、修改、銷售、改編、匯編和翻譯出版等侵權行為，ODCC及有關單位將追究其法律責任，感謝各單位的配合與支持。IIServiceTelemetry 數據采集方案白皮書ODCC-2022-03009編制說明編制說明本報告在撰寫過程中得到了多家單位的大力支持，在此特別感謝以下參編單位和參編人員：參編單位（排名不分先后）：騰訊、百度、中國移動、美團、博通、華三、華為、銳捷、中國信通院（云大所）參編人員（排名不分先后）：胡小媛、包貴新、秦鳳偉、杜海峰、何宗應、晏思宇、楊揚、馮耀烽、孫聰、王少鵬IIIServiceTelemetry 數據采集方案白皮書ODCC-202

3、2-03009前言前言在云化和 AI 時代，數據中心網絡由數十萬級的交換機設備、百萬級的網卡和數千萬級網絡實例組成，并不斷在隨著業務動態變化，復雜性遠超以往。計算資源池化、存儲資源池化后產生的指數級數據流量增長給數據中心網絡的運營帶來了嚴峻挑戰。我們改變傳統網絡管理工作的思路，設計了面向應用的ServiceTelemetry 平臺，采用應用看網絡的視角，基于大數據技術結合 AI 算法實現應用流模型畫像，解決故障發現難、診斷難和界定難的問題，并提供應用瓶頸識別，性能優化、故障規避和預測等網絡服務能力。本文著重介紹ServiceTelemetry 平臺的幾個應用場景以及對應的技術實現、采集規范等內

4、容。IVServiceTelemetry 數據采集方案白皮書ODCC-2022-03009目錄目錄版權聲明.I編制說明.II前言.III一、背景.1（一）網絡遙測技術.1（二）面向應用的網絡遙測技術（Service Telemetry）.1二、應用場景.3（一）場景一：應用畫像.31 業務染色.32 業務實例畫像.43 業務實例轉發路徑.44 數據定義.5（二）場景二：微突發監控.61 微突發的定義.62 微突發的原因.73 微突發的影響.84 微突發監控的實現.85 微突發數據分析.96 數據定義.9三、采集規范.10（一）系統架構.10VServiceTelemetry 數據采集方案白皮書

5、ODCC-2022-03009（二）下發和采集規范.101 下發方式.102 上報方式.141ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009一、背景一、背景圖 1 傳統網絡遙測技術與 Service Telemetry 的對比圖（一）網絡遙測技術（一）網絡遙測技術廣義上說，網絡遙測技術（Telemetry）是指從設備上采集高精度數據，為網管系統定制信息、并通過設備實時主動推送數據的技術。不同于傳統網絡測量技術采集數據以 IP 報文格式呈現給分析工具，網絡遙測技術通常使用“推模式”，支持亞秒級精度的數據采集和格式化數據傳輸。（二）面向應用的網絡遙測技術（Ser

6、vice Telemetry）（二）面向應用的網絡遙測技術（Service Telemetry）圖 2 基于 Service Telemetry 的業務監控框架在云化和 AI 時代，業務對網絡提出了新的要求，Service Telemetry 實現了從單一的網絡質量監控到業務與網絡聯合監控的轉變，同時實現了從設備運維到業務通信運維的升級。要求一：業務質量精確可視2ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009承載著基礎轉發能力的物理網絡任何一個小問題都會影響到應用的質量，傳統的網絡運維視角只關注帶寬使用情況，丟包具體內容和原因等指標，但這些指標對業務的性能產

7、生多大的影響，無法有效的關聯。只有將網絡指標和應用指標相互關聯，構建出業務流的畫像的系統，才能精確度量出應用的運行情況。要求二：分布式應用不斷升級，如何優化長尾 IO隨著應用架構逐漸向分布式發展，導致大量 incast 突發流量網絡上涌現，多種硬件卸載技術被廣泛應用，更快更輕的網絡通信方式相繼涌現，這也進一步增大網絡吞吐壓力。同時存儲介質的不斷升級，網絡 IO 時延問題進一步成為制約存儲性能提升的關鍵瓶頸問題，唯有準確查找出存儲長尾時延 IO 及其具體成因，才能有針對性地采取有效優化措施。要求三：問題快速界定大規模的網絡故障發現難，問題界定更難，比如網絡微突發抖動很常見并不易感知，而應用對時延

8、的抖動問題卻很敏感。需要分析瓶頸在應用側還是網絡設備，原因具體是什么，該怎樣解決誰來解決?；凇耙詰脼橹行牡木W絡”理念，我們提出 Service Telemetry 的概念，向業務提供高精度、更加豐滿和定制化的數據，幫助業務打開網絡的黑盒子，為未來向業務故障預測、應用驅動網絡等愿景前進打下基礎。Service Telemetry 為業務提供的核心能力包括：應用模型畫像度量業務實例性能影響的關鍵指標：比如 TPSQPSIOPS、IO 抖動、長尾 IO。業務瓶頸識別：帶寬、時延敏感流識別。高精度網絡度量3ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009實現微突發

9、現象監控和自愈；實現業務流量端到端逐跳時微秒級度量。隨流技術檢測精確測量每條業務的丟包率/時延信息；精確還原業務轉發面路徑信息背景。二、應用場景二、應用場景（一）場景一：應用畫像（一）場景一：應用畫像應用畫像功能是在 ServiceTelemetry 平臺實現業務的關鍵數據采集和多維度分析，輸出的分析報告，包括對業務流維度的端到端完成時間和在每個網絡節點的逐跳時延，比如 TPSQPSIOPS，以及 latencyp99、p999 等關鍵指標的評估分析。只有將網絡指標和應用指標映射關聯，構建出業務流的畫像的系統，才能精確度量出應用的運行情況。1業務染色1業務染色應用架構分布式發展、多種硬件卸載技

10、術廣泛應用，對于應用畫像精確度、數據處理能力等方面都提出了巨大挑戰，沒有辦法采集并分析全部業務流量，必須更加有的放矢地選取具體關鍵流程報文進行染色、達到精準度量而不額外增加網絡通信開銷。針對這一問題，Service Telemetry 實現了的關鍵業務流識別方法，此類關鍵業務流以消息較小且內容完整為主要特征，通常包括業務實例的類型，任務消息大小和種類，任務開始和完成標識等信息，一般為控制報文，這類報文通常與數據傳輸的流使用相同的鏈接，也就有相同的網絡轉發路徑，因此只需對此類關鍵業務流進行染色識別即可。業務在對數據結構定義時，在 IP 報文四層頭后面插入特定報文頭標記報文（染色字段），并打上相應

11、的時間戳。4ServiceTelemetry 數據采集方案白皮書ODCC-2022-030092業務實例畫像2業務實例畫像業務端染色完成后，進入接入層網絡設備，設備在轉發芯片內建立一個業務實例表 Service_Table，以業務實例報文源 IP、目的 IP 及業務實例序號（Service_Seq）唯一標識一個業務實例，這個表里同時還記錄該實例的時間戳、業務實例類型、業務實例編號、業務實例傳輸大小等信息；并Parser 解析業務 IP 報文頭，判斷業務實例編號（Service_Seq）在Service_Table 中不存在時，則創建一條實例表項；如該業務實例編號（Service_Seq）在 S

12、ervice_Table 中已存在，判斷業務實例類型，并根據Service 類型更新 Service_Table 中該實例的內容；在識別出一個業務實例的完成報文（Service_Resp），更新時間戳，并將 Service_Table 中記錄的該業務實例表項封裝為 Service Telemetry stream 上送分析平臺，同時網絡設備本地刪除該條表項記錄；分析平臺實時進行數據的分析和統計，比如針對不同消息大小的業務實例，不同時段的業務實例，進行測量比較，評估業務的健康狀態。還可以深入進行多維度的分析，比如業務實例時延分布情況、長尾 IO、IO 抖動和性能瓶頸等等。3業務實例轉發路徑3業務

13、實例轉發路徑當 ServiceTelemetry 平臺分析發現業務性能的一些異常情況，比如業務實例 IO 長尾時延數據對比典型值的波動超出閾值，則可以針對性觸發對該業務實例的轉發路徑的探測，采集該業務實例在整個網絡上完整轉發路徑，以進一步對網絡進行分析，找出問題網絡設備或者鏈路。具體過程如下：Service Telemetry 分析器觸發業務的發起端服務器發出業務質量探針報文，染色并打時間戳，在逐跳的網絡設備上對探針報文打上入、出時間戳，入、出網絡端口信息，網絡設備 ID，網絡設備質量狀態等信息，目的服務器收到業務探針報文，打上時間戳并復制封裝上送 Service Telemetry 分析器，

14、同時發送業務響應報文，染色并打時間戳，以完成對回程報文轉發路徑的采集；Service Telemetry 分析器可以根據業務報文的雙向轉發路徑，根據時間戳信息得出該雙向轉發路徑各自的網絡時延，從而評估該業務完整轉發路徑的健康狀態，快速準確的找到問題設備節點。5ServiceTelemetry 數據采集方案白皮書ODCC-2022-030094數據定義4數據定義業務實例數據表（Service_Table）定義屬性屬性含義含義數據類型數據類型數據長度數據長度Destination IP業務實例響應端IP地址int4BSource IP業務實例發起端IP地址int4BService Sequence

15、業務實例序列號int2BService Type業務實例類型int1BService Size業務實例大小int1BTimestamp業務發起時間double4BTimestamp Update業務最近更新時間double4B業務實例轉發路徑表定義：屬性屬性U含義U含義數據類型數據類型數據長度數據長度Device-ID網絡設備IDint4ByteCongestion擁塞標志位int5bitDrop Pkt業務實例序列號int1ByteIP TTL報文的TTL值int1ByteRx Timestamp入接口時間戳double2ByteTx Timestamp出接口時間戳double2ByteIn

16、gress Port入接口int2Byte6ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009Egress Port出接口int2Byte配置下發數據定義屬性屬性含義含義數據類型數據類型數據長度數據長度Device ID網絡設備IDint1ByteCollector address采集器IP地址int4ByteDestination port采集器端口號int2ByteSource address網絡設備上送源IPint4ByteSource port網絡設備上送源端口int2Byte業務實例異常數據表屬性屬性含義含義數據類型數據類型數據長度數據長度Destin

17、ation IP業務實例響應端IP地址int4ByteSource IP業務實例發起端IP地址int4ByteService Sequence業務實例序列號int2ByteError Type異常類型int1Byte（二）場景二：微突發監控（二）場景二：微突發監控1微突發的定義1微突發的定義業務流量微突發（Microburst）是數據中心網絡中一種常見的現象，是端口在非常短的時間（毫秒級別）內收到非常多的突發數據，典型的微突發的持續時間通常在 1100 毫秒之間，以至于瞬時突發速率達到平均速率的數十倍、數百倍，甚至超過端口帶寬的現象。微突發流量會降低數據中心業7ServiceTelemetry

18、 數據采集方案白皮書ODCC-2022-03009務的性能。微突發流量會導致網絡丟包，影響到業務的性能。但是傳統的網絡帶寬監控的粒度比較粗，snmp 的監控是分鐘級別，Telemetry 的最大的精度也只能做到秒級，而要發現網絡環境中的微突發現象，通常需要 ms 級別的高精度監控。如圖 3.1，實際的微突發流量是綠色曲線，監控平臺往往讀到的是顆粒度比較粗的藍色流量曲線，無法及時監控到微突發現象。圖 3 數據中心流量業務微突發場景2微突發的原因2微突發的原因業務流量存在波動：很多通用的業務模型下，用戶的請求和服務器的響應是離散出現的，導致業務流量是間歇性的，不穩定。同時對時延和帶寬敏感的業務要求

19、盡快發送數據，加劇業務的突發性。傳統的 TCP 發包原則：通過慢啟動和擁塞避免機制，盡快將數據包發送出去。慢啟動使得發送速率不會快速上升。當吞吐量達到上限后，TCP 滑動窗口減半，速率迅速下降，導致會話流量呈鋸齒狀，具有突發性。TCP 總是期望把發送窗口中的數據盡快發送完，所以會在等待 TCP 的報文到達確認（ACK）到來后，通過滑動窗口機制再繼續發送數據，如此循環，使得發包速率不平緩，突發性強。流量的入端口總帶寬和超過出端口的總帶寬。廣泛存在在數據中心的分布式應用，會存在高帶寬端口向低帶寬的出端口轉發流量、多個入端口向一8ServiceTelemetry 數據采集方案白皮書ODCC-2022

20、-03009個出端口轉發流量。以及網絡設備上不適當的 QoS 參數配置，如隊列調度和端口限速。設計不合理的 UDP 通信程序，短時間內發出大量 burst 包，不做延時。3微突發的影響3微突發的影響當微突發流量的瞬時速率超過網絡設備的轉發能力時，網絡設備會將突發的數據進行緩存以便稍后發送。但是在數據中心網絡里大多采用小緩存的盒式網絡設備，一旦緩存溢出，會導致出現大量丟包的情況，影響到業務性能。4微突發監控的實現4微突發監控的實現傳統監控微突發的方案是針對所有的流量進行實時的監控和統計，利用流表來記錄五元組并持續計數，但受限于網絡設備芯片流表容量，無法做到全量監控，同時因為突發是微秒級別，并瞬間

21、存在，控制面無法及時捕獲。更重要的是，網絡運營團隊對微突發和丟包問題不僅需要精確發生的時間，更需要準確知道發生導致微突發現象具體報文的內容以及關聯的具體業務。Service Telemetry 平臺的微突發監控重點針對這幾方面的難點進行優化，實現了高效準確的微突發監控。具體實現方法：交換機的 MMU 上設定微突發開始水線和微突發停止水線（水線代表在一個時間窗口內的緩存計數），當交換芯片收到的報文超過微突發開始水線，就給后續報文都打上微突發標記，當收到的報文超過 MMU 丟棄水線時打上丟棄標記。在交換機出方向匹配到 microburst 標記位時，從報文中抽取五元組信息并以精確匹配方式查找該設備

22、的微突發五元組流表，如果沒有命中則意味這這是一條受本微突發影響的新流因而在該表中插入一條新條目，包括五元組，時間戳、入口端口信息、隊列信息、出口隊列緩存的使用率等，設備啟動針對該五元組進行 counter 計數（pkt 數和 Byte 數）。9ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009同時設備啟動啟用周期性定時器，當設備長時間不再檢測到該流存在擁塞或者報文緩存回落到微突發結束水線，則認為擁塞現象已經消失，發送最后一個 Service Telemetry Stream 后流表老化，并釋放相關資源。5微突發數據分析5微突發數據分析所有微突發流上送到 Serv

23、ice Telemetry 后，以上送時間窗口和單臺網絡設備為一個獨立的分析單元，統計每個分析單元內的所有流微突發的持續時間，報文技術等指標，得出對業務造成關鍵影響的業務流量。6數據定義6數據定義屬性屬性含義含義數據類型數據類型數據長度數據長度CPU Timer基于流的微突發信息上送Collectorint1Bytesdrop Cn-byte微突發導致丟包數字節數int2Bytesdrop Cn-pkt微突發導致丟包數int2BytesDrop threshold微突發丟包水線int2BytesFinish threshold微突發buffer結束水線int2BytesFinish Timer

24、多少時間沒有收到微突發采樣報文，判斷為微突發結束int4Bytes10ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009Microburst Cnt-byte微突發的報文字節數int2BytesMicroburst Cnt-pkt微突發的報文數int2BytesSample按多少進行采樣int2BytesStart threshold微突發buffer觸發水線int2Bytes三、采集規范三、采集規范（一）系統架構（一）系統架構圖 4 Service Telemetry 的系統框架（二）下發和采集規范（二）下發和采集規范1下發方式1下發方式（1）gRPC Dia

25、l-in 模式與 Telemetry 類似，Service Telemetry 也在向設備下發配置的場景采用 gRPC Dial-in 模式，設備作為 gRPC 服務器，采集器作為 gRPC 客戶端。由采集器主動向設備發起 gRPC 連接并訂閱需要采集的數據信息。11ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009交互協議、接口這里與 Telemetry 的下發模式一致，采用 gnmi 的標準 set 接口進行下發配置。protobuf 內容層定義SetRequestSetResponse12ServiceTelemetry 數據采集方案白皮書ODCC-202

26、2-0300913ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009數據結構說明：下發配置，path 需要指定 key 值，且 path 路徑為 leaf 的上一層節點或 leaf。關于 update 中的 val 字段，TypedValue 這里支持很多類型的數據，這里統一使用 json_val 類型，以便統一解析 yang 的 json。如果同一個 key 值 下有多個子 KEY，請封裝到多個 updata 消息下發。path 的 element 內容中，無須帶 yang 文件的前綴。以保證 path 可以還原為 xpath。14ServiceTelemet

27、ry 數據采集方案白皮書ODCC-2022-030092上報方式2上報方式（1）ServiceTelemetry Stream 模式ServiceTelemetry Stream 可以部署在網絡的接入層、匯聚層、核心層，是指通過對業務報文的處理對業務實例質量進行測量、統計和分析，并將統計結果上報給采集器，合并處理后存入 Service Telemetry 分析平臺。Service Telemetry Stream 可以將業務實例類型、業務實例大小，完成時間和健康狀態等信息以及這個業務實例實際轉發路徑上的每臺網絡設備端口、隊列信息、以及每一跳的耗費的時延的時間戳信息封裝成標準 IP 報文。封裝報

28、文的格式使用標準的 IPFIX 消息頭(Message Header)，再根據不同的應用場景，利用 IPFIX 的擴展性增加定義不同的 Sets。Service Telemetry Stream Header Format屬性含義數據類型數據長度VersionIPFIX版本int2ByteLength采集器IP地址int2ByteExport TimeIPFIX消息頭離開Exporter的時間，表示自1970年1月1日起的UNIX時間的秒數int4ByteSequence Number報文序列號int4Byte15ServiceTelemetry 數據采集方案白皮書ODCC-2022-0300

29、9Observation DomainID上送的網絡設備int4ByteTemplate Set Format業務畫像 Stream set 定義微突發監控 Stream set 定義16ServiceTelemetry 數據采集方案白皮書ODCC-2022-0300917ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009（2）gRPC dial-out 模式采用基于 gRPC 的設備可以自動讀取各種統計網絡數據信息，根據訂閱要求將采集的信息通過 gRPC 協議上報給采集器，實現了比傳統監控方式更加實時、高效的數據采集功能。gRPC dial-out 模式網絡設

30、備主動上報訂18ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009閱內容至 Service Telemetry 采集器 agent。網絡設備作為 clients 端，ServiceTelemetry 分析平臺作為 server 端，設備主動和采集器建立 gRPC連接，將設備上配置的訂閱數據推送給 ServiceTelemetry 分析平臺。交互協議協議、接口ServiceTelemetry 數據上報使用 gRPC 方式。通信協議主要考慮要素:使用 protobuf 作為通信協議，周期性數據優先選擇采用 stream 流式方式；一次 request 請求的上報的數據盡量豐富，減少設備與系統交互次數；使用開源公共協議，減少不同網絡設備與網管系統側的業務邏輯適配，便于擴展與維護。protobuf 內容層定義SubscribeResponseNotification19ServiceTelemetry 數據采集方案白皮書ODCC-2022-03009Update