03字节跳动超大规模 Metrics 数据采集的实践和探索--刘浩杨.pdf

《03字节跳动超大规模 Metrics 数据采集的实践和探索--刘浩杨.pdf》由会员分享，可在线阅读，更多相关《03字节跳动超大规模 Metrics 数据采集的实践和探索--刘浩杨.pdf（35页珍藏版）》请在三个皮匠报告上搜索。

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 引擎联系我加入我们团队