03字節跳動超大規模 Metrics 數據采集的實踐和探索--劉浩楊.pdf

1、字節跳動超大規模 Metrics 數據采集的實踐和探索字節跳動-基礎架構-研發工程師/劉浩楊關于我就職于字節跳動 DevInfra 可觀測性團隊APM 接入側方向負責人有6年+的開源社區運營經驗Apache SkyWalking PMC 成員目錄字節可觀測性平臺概覽海量 Metric 數據采集的挑戰海量 Metric 數據采集優化實踐未來展望三位：MetricsTracingLogging一體：一個平臺一套存儲字節可觀測性平臺構建思路字節可觀測性平臺構建思路上下文串聯過濾、聚合字節可觀測性平臺整體架構目錄字節可觀測性平臺概覽海量 Metric 數據采集的挑戰海量 Metric 數據采集優化實踐

2、未來展望字節 Metrics 平臺技術挑戰Agent 部署實例百萬級Agent 接收1000億+dp/sMetric 寫入50億+dp/s查詢QPS 100K+字節 Metrics 平臺業務挑戰服務集群數十萬+微服務實例數千萬級后端主流研發語言4 RPC框架 10+服務發布日均數萬次 核心業務QPS 千萬級 P99延遲10ms 鏈路深度50 字節時序數據庫ByteTSDByteTSD 使用方式數據類型：Counter/Meter/Gauge/Histogram/Summary寫入：SDK(Go/Java/C+/Python)查詢：實現OpenTSDB查詢語法，可通過Grafana、Bosun、

3、OpenAPI接入ByteTSD 接入方式輕SDK：OpenTSDB Protocol打點精度：Agent 30s 聚合上報方式：Push引入問題：支持場景受限自定義配置：如秒級打點主動采集：業務需自研 Agent引入問題：SDK 序列化瓶頸某吞吐量為200w/s Flink ETL 任務做埋點統計，Metric SDK 打點消耗 CPU 占比 36%引入問題：Agent 資源成本裝機量百萬數量級每臺宿主機需要 2C4G 資源目錄字節可觀測性平臺概覽海量 Metric 數據采集的挑戰海量 Metric 數據采集優化實踐未來展望全局優化：Metric多值存儲成本(Tags復用)多Field查詢加

4、速多Field復雜計算全局優化：私有Codec流式編碼和讀取高壓縮率全局優化：SDK聚合減少序列化自定義打點精度降低 Agent 負載Agent 聚合優化租戶數據隔離Pool-Alloc for stringSIMD 加速zlib vs zstd vs snappyOffload to DPUSDK優化：分層設計SDK優化：無鎖 KDTree并發讀寫基于 string 內存對比Sharding Collector傾斜時退化為 HashMapSDK優化：多段Metric索引復用 Tags 減少索引次數SDK優化：Structured API增量 APIType SafedTags 預處理性能提升

5、SDK優化：series query debug優化收益：數據服務某吞吐量為200w/s Flink ETL 任務做埋點統計，Metric SDK 打點消耗 CPU 占比從 36%降低到 7.14%優化收益：在線服務優化收益：整體評估8000000*3%=240000 Cores 目錄字節可觀測性平臺概覽海量 Metric 數據采集的挑戰海量 Metric 數據采集優化實踐未來展望OneAgent&DataPipelineM.T.L 數據數據上報+主動采集插件化 Pipeline流式計算開源 Agent 對比開源共建已提交Merge PR 30+Metric/Trace 原生數據模型Metric 寫入到 influxdb 支持插件可分離在獨立代碼倉庫計劃中運維控制面協議自監控、租戶數據隔離DAG based PipelineSQL 引擎聯系我加入我們團隊