03_舒博-字節跳動觀測數據埋點標準化實踐.pdf

《03_舒博-字節跳動觀測數據埋點標準化實踐.pdf》由會員分享，可在線閱讀，更多相關《03_舒博-字節跳動觀測數據埋點標準化實踐.pdf（31頁珍藏版）》請在三個皮匠報告上搜索。

1、字節跳動觀測數據埋點標準化實踐舒博字節跳動可觀測團隊 高級工程師大綱 背景 埋點標準化的挑戰與拆解思路 實踐與效果 總結背景隨著字節業務規模越來越大，穩定性治理穩定性治理 就成為了一個越來越重要的話題。就成為了一個越來越重要的話題。觀測數據標準化 及 配套的數據鏈路就是后續穩定性建設的數據基石。統一的觀測數據標準，可以極大程度提升團隊間排障效率，從人肉分析提升到更大程度自助/自動化排障的階段。埋點標準化的重要性提高研發效率且降低研發協同成本為AIOps 提供強有力的數據支撐提高研發效率且降低研發協同成本面向排障:跨層間 上下文過濾便捷并統一術語歷史數倉分析 整體pipeline 邏輯和適配成本

2、降低很多降低用戶的學習曲線 以及 心智理解負擔為AIOps 提供強有力的數據支撐清華大學裴丹老師的 的架構路線 也提到了 數據的重要性：數據知識驅動、算法代碼聯動、人機協同觀測數據是基石之一有了數據標準化和統一的訪問體驗，為后續穩定性終極目標 MTTR 1-5-10 提供了數據層面的保障，包括同層數據的聚合/過濾 以及跨層數據的下鉆和上卷 都會有統一的使用姿勢。埋點標準化的挑戰與拆解思路挑戰：挑戰：歷史上可觀測性埋點質量偏低歷史上可觀測性埋點質量偏低思路：思路：分層分層&向后兼容推進埋點標準化向后兼容推進埋點標準化卡點：卡點：識別和解決識別和解決埋點標準化的定義埋點標準化的定義：覆蓋完整覆蓋完

3、整定義統一定義統一計量準確計量準確面向引擎友好面向引擎友好M.T.L 橫向覆蓋是否完整橫向覆蓋是否完整定義統一定義統一計量準確計量準確面向引擎友好面向引擎友好TLBN/A高中之前打點丟失問題較嚴重低之前指標打點 對于配置預計算不友好指標名膨脹也比較嚴重微服務中20 年前 Tracing 方案還在 V1 版本高中之前遇到高基數的指標會被封禁低之前指標打點 對于配置預計算不友好指標名膨脹也比較嚴重加權計算也不好實現語言 runtime N/A低Golang&c+框架 不同的版本定義的指標格式都不太一樣高低之前指標打點 對于配置預計算不友好容器指標低沒有日志采集覆蓋高中之前遇到高基數的指標會被封禁低

4、之前指標打點 對于配置預計算不友好基礎架構 存儲&數據庫低存儲、數據庫、MQ 客戶端也沒有黃金指標打點沒有日志采集覆蓋低不同存儲、數據庫、MQ 產品打點格式 都不一中低之前指標打點 對于配置預計算不友好2020 年之前，字節整體觀測數據埋點質量情況服務端觀測數據質量大致分 3 類問題：同層數據/跨層數據不統一 觀測多模態數據類型 指標、日志、鏈路數據定義不統一 觀測數據格式面向引擎不夠友好，比如所有的數據都在 default 租戶一個大倉，再如很多觀測指標定義對于預計算不友好。思路：思路：分層和向后兼容推進埋點標準化分層和向后兼容推進埋點標準化問題一問題一 同層數據同層數據/跨層數據不統一跨層

5、數據不統一解決方案解決方案:協作組件設計打點規范協作組件設計打點規范微服務RPC:引入多租戶+多值&對齊TagKV 術語TLB:引入多租戶+多值&面向預計算友好容器指標:引入多租戶+多值&對齊TagKV 術語:思路：思路：分層和向后兼容推進埋點標準化分層和向后兼容推進埋點標準化問題二問題二 觀測多模態數據類型觀測多模態數據類型指標、日志指標、日志、鏈路數據定義不統一解決方案解決方案:采集覆蓋采集覆蓋+埋點術語統一埋點術語統一日志采集覆蓋:微服務+容器鏈路覆蓋:SDK 基線版本升級TLB:引入多租戶+多值&面向預計算友好多模觀測數據埋點術語統一:統一 M.T.L SDK TagKV定義;埋點ve

6、ndor SDK 感知運行時環境 定義TagKV 思路：思路：分層和向后兼容推進埋點標準化分層和向后兼容推進埋點標準化問題三問題三 觀測數據格式面向引擎不夠友好觀測數據格式面向引擎不夠友好解決方案解決方案:指標標準化引入metrics 2.0 多租戶&多值:2.0 SDK 在性能開銷&傳輸效率都優于1.0團隊歷年來在多個觀測對象團隊歷年來在多個觀測對象上埋點做出的業務推進上埋點做出的業務推進卡點卡點:識別和解決識別和解決如何高效推動業務升級？如何高效推動業務升級？如何進一步提升核心組件的埋點質量？如何進一步提升核心組件的埋點質量？如何保障觀測數據遷移對于在線核心觀測大盤和報警影響最小化？如何保

7、障觀測數據遷移對于在線核心觀測大盤和報警影響最小化？如何降低對接的人力成本？如何降低對接的人力成本？如何高效推動業務升級如何高效推動業務升級BytedTrace SDK 集成集成RPC 框架框架BytedTrace 團隊為公司常用框架和組件集成了 BytedTrace SDK。目前對于大部分 RPC 框架和存儲端 Client 都已完成。按服務優先級來看，公司當前 P0 服務已有 94%接入 Bytedtrace SDKlevelV2 服務服務 接接入率入率V1+V2 服務服務接入率接入率V2 服務服務數數V1+V2 服務服務數數服務服務 總數總數P00.95460.9597168216911

8、762P10.89880.9150200820442234P20.82330.8577596462137244P30.81900.8558267279326如何高效推動業務升級如何高效推動業務升級聯合 bytesib 團隊計劃實現 sdk 自動升級功能如何進一步提升核心組件的埋點質量？如何進一步提升核心組件的埋點質量？容器容器/Runtime 打點格式打點格式 設計思路設計思路層次核心組件/著手點埋點標準化設計思路業務層Metrics 2.0 SDK內置統一公共的TagKV，提供橫向跨語言、跨服務的TagKV統一應用層Runtime 指標、RPC 指標橫向上，提供統一的、跨語言的指標名定義縱向

9、上，對齊Metrics 2.0 SDK公共TagKV規范容器層與調度合作，對容器指標采集agent(sysprobe)進行標準化改造對齊Metrics 2.0 SDK公共TagKV規范如何保障觀測數據遷移對于在線如何保障觀測數據遷移對于在線核心觀測大盤和報警影響最小化？核心觀測大盤和報警影響最小化？推動SDK的升級，指標名、TagKV的語義統一，必然會引起存量觀測大盤、報警規則的不一致?？窗逶谇Ъ墑e數量級、涉及的報警規則的數量在十萬級別如何保障觀測數據遷移對于在線如何保障觀測數據遷移對于在線核心觀測大盤和報警影響最小化？核心觀測大盤和報警影響最小化？語義化指標替換語義化指標替換-Measure

10、ment 對原始 metrics 打點的語義化封裝識別在不同條件下，能使用對應版本的指標查詢以及對應的 tagkv如何保障觀測數據遷移對于在線如何保障觀測數據遷移對于在線核心觀測大盤和報警影響最小化？核心觀測大盤和報警影響最小化？1.通過元信息獲取觀測對象的信息2.根據信息和處理邏輯，選擇應使用的standardmetrics。3.根據輸入region等信息和standardmetrics的datasource type，獲取數據引擎和數據源endpoint。4.渲染standardmetrics的query語句，參數為:1.指標中的具體觀測對象實體2.經過預先設定的mapping映射，將各個

11、指標之間有差異的tag key 對齊。5.根據渲染完成的query 去數據引擎層中請求對應的數據源endpoint 獲得數據。如何保障觀測數據遷移對于在線如何保障觀測數據遷移對于在線核心觀測大盤和報警影響最小化？核心觀測大盤和報警影響最小化？rpc、http框架，tce容器、faas、bernard平臺、以及tlb、redis、mysql、bytedoc、bmq、rmq等基礎組件，及go runtime等都做了統一的標準化語義封裝。這些語義化封裝在服務端Argos觀測平臺上都有體現。抽象出 measurement 服務作為觀測大盤和報警的一個數據源。在盡量不需要用戶介入的情況下完成數據打點的遷

12、移和替換，這里包括觀測大盤和報警能力如何保障觀測數據遷移對于在線如何保障觀測數據遷移對于在線核心觀測大盤和報警影響最小化？核心觀測大盤和報警影響最小化？Metrics 前綴分流前綴分流幫助業務平滑遷移到新租戶，且確保新老指標查詢方式都可查詢,是推動業務租戶遷移中遇到比較大的課題。Metrics團隊發起對用戶無感知的被動租戶遷移方案-如何保障觀測數據遷移對于在線如何保障觀測數據遷移對于在線核心觀測大盤和報警影響最小化？核心觀測大盤和報警影響最小化？根據特定的指標前綴，一級/二級前綴經過配置將指標分別路由到不同的新租戶在新租戶上支持查詢翻譯，支持在用戶不修改查詢租戶的情況下，使用Default租戶

13、查詢依然可以正常查詢到數據如何降低對接的人力成本？如何降低對接的人力成本？獨立租戶自助申請。租戶創建表單提供了非常多的定制化參數給到用戶，用戶可以結合自己的使用場景，比如業務打點精度、部署的機房、熱存的保存時長、是否需要使用冷存等，來定制化獨立租戶。租戶變更申請。在使用過程中，用戶可以根據實際使用情況來調整租戶運行中的一些參數，比如數據存儲策略、寫入管控策略。metrics 租戶運營平臺化租戶運營平臺化實踐與效果實踐與效果-標準化質量體現標準化質量體現M.T.L 橫向覆蓋是否完整橫向覆蓋是否完整定義統一定義統一計量準確計量準確面向引擎友好面向引擎友好成本收益成本收益TLBN/A高高20 年前

14、低通過 2.0 SDK 三個特性，基本消除丟點的問題高 20 年前 低實際效果：面向預計算友好1.Metrics 2.0 打點商品成本相對 1.0 下降下降94%。2.Metrics 2.0 很好地解決了打點封禁問題，特別是在一些配置量巨大的核心集群，解決了其超過 90%打點無法查詢的情況。3.Metrics2.0 TLB 機器成本初步統計主容器和 adaptor 打平，同時相對 1.0 節約了 ms2 的 15000 核資源。微服務高 20 年前 中80%以上 PSM 覆蓋到bytedTrace SDK 集成高中+高基數的指標封禁問題 由于遷移到了新租戶 可以做封禁閾值定制化計劃中 升級 b

15、ytedTrace 內的metrics 2.0 SDK 降低丟點的風險高 20 年前 低實際效果：面向預計算友好1.以計算關鍵組件 Consumer 為例，新租戶只需要老租戶新租戶只需要老租戶20%的資的資源源，就可以完成相同數據的寫入計算（下面說明會介紹推導方法）；其他寫入計算類組件也類似2.以存儲關鍵組件 tsdc 為例，新租戶只需要老租戶新租戶只需要老租戶55%的資源的資源，就可以完成想通過數據的寫入、存儲語言 runtime N/A高 20 年前 低統一了不同語言和框架的 runtime 打點格式高低容器指標中 20 年前 低Godel 接入日志租戶高高 20 年前 中引入多值 降低指

16、標名數量高基數的指標封禁問題 由于遷移到了新租戶 可以做封禁閾值定制化通過 2.0 SDK 三個特性，基本消除丟點的問題高 20 年前 低之前指標打點 對于配置預計算不友好進行中基礎架構 存儲&數據庫低進行中 目前有 10+組件 在接入 metrics 2.0 SDK+租戶獨立低不同存儲、數據庫、MQ 產品打點格式 都不一高 20 年前 中引入多值 降低指標名數量高基數的指標封禁問題 由于遷移到了新租戶 可以做封禁閾值定制化通過 2.0 SDK 三個特性，基本消除丟點的問題中 20 年前 低打點格式調整的支持預計算配置以 mysql 遷移為例Mysql 租戶 成本節省節省45。7%Mysql

17、租戶 帶寬節省了節省了80%實踐與效果實踐與效果-效果總結效果總結賦能賦能AIOps 跨層根因定位跨層根因定位通過指標標準化&多模觀測數據 指標，日志，鏈路標簽術語的標準化，實現面向微服務的上卷&下鉆關聯分析。也使得跨層問題根因分析有了可能性實踐與效果實踐與效果-效果總結效果總結Metrics 存儲收益存儲收益穩定性：由于定義了租戶，就可通過邏輯租戶映射到物理資源來降低故障半徑，減少不同租戶間流量相互干擾。成本：通過每個租戶的副本數&存儲時長 TTL 以及打點最小精度 和 多值定義來最大程度降低寫入流量 以及存儲容量的成本。流量來看，流量來看，老集群：1.寫入網關流量下降：6.5%2.寫入網關

18、視角：byetrace指標在新租戶流量只有老租戶的 17.6%3.BMQ入流下降：12.3%14%4.tsdc DataPoint流量下降：9.7%關鍵資源使用關鍵資源使用看，老集群：1.Producer平均cpu使用率下降：8.2%2.consumer平均cpu使用率下降：9.5%3.Streaming平均cpu使用率下降：26.5%4.tsdc內存使用下降：13.2%總結與規劃總結與規劃經過近 3 年的 bytedTrace 推廣&metrics 2.0 租戶遷移，字節后端觀測數據質量 無論在覆蓋完整度、定義統一、計量準確、面向引擎友好四個方面都有相當程度的改善，也為后續全景全棧排障 進而 AIOps 提供了堅實的基礎。未來會在如下兩方面繼續推進未來會在如下兩方面繼續推進：協助服務端觀測平臺的監控和報警方向 進一步閉環上述標準化數據訪問、下線老數據的寫入流量 以及推廣到全球的多區域；推動火山引擎云產品接入上述的數據標準化，提供內外一致的數據質量體驗。感謝聆聽Thank you for listening