字节跳动超大规模 Metrics 数据采集的实践和探索
字节可观测性平台概览
字节跳动的可观测性平台采用 Metrics、Tracing、Logging 一体化架构,通过上下文串联和过滤聚合能力,实现数据统一存储和管理。
海量 Metric 数据采集的挑战
- 技术挑战:Agent 部署实例百万级,Agent 接收 1000 亿+ dp/s,Metric 写入 50 亿+ dp/s,查询 QPS 100K+。
- 业务挑战:服务集群数十万+,微服务实例数千万级,后端主流研发语言 4 种,RPC 框架 10+,服务发布日均数万次,核心业务 QPS 千万级,P99 延迟 10ms,链路深度 >50。
时序数据库 ByteTSD
- 数据类型:Counter/Meter/Gauge/Histogram/Summary。
- 使用方式:写入通过 SDK (Go/Java/C++/Python),查询支持 OpenTSDB 语法,可通过 Grafana、Bosun、OpenAPI 接入。
- 接入方式:轻 SDK 支持 OpenTSDB Protocol,打点精度 30s 聚合,上报方式 Push。
- 存在问题:支持场景受限(自定义配置、主动采集),SDK 序列化瓶颈(200w/s Flink ETL 任务 CPU 占比 36%),Agent 资源成本高(百万量级,每台 2C4G 资源)。
海量 Metric 数据采集优化实践
全局优化
- Metric 多值优化:存储成本降低(Tags 复用),多 Field 查询加速,多 Field 复杂计算优化。
- 私有 Codec:流式编码和读取,高压缩率。
- SDK 聚合:减少序列化,自定义打点精度,降低 Agent 负载。
Agent 聚合优化
- 租户数据隔离。
- Pool-Alloc for string。
- SIMD 加速。
- zlib vs zstd vs snappy。
- Offload to DPU。
SDK 优化
- 分层设计。
- 无锁 KDTree:并发读写,基于 string 内存对比,Sharding Collector,倾斜时退化为 HashMap。
- 多段 Metric 索引:复用 Tags,减少索引次数。
- Structured API:增量 API,Type Safed,Tags 预处理,性能提升。
- series query debug。
优化收益
- 数据服务:200w/s Flink ETL 任务 Metric SDK CPU 占比从 36% 降低到 7.14%。
- 在线服务。
- 整体评估:节省 240000 Cores(8000000 * 3%)。
未来展望
- OneAgent & DataPipeline:支持 M.T.L 数据,数据上报 + 主动采集,插件化 Pipeline,流式计算。
- 开源 Agent 对比:已提交 Merge PR 30+,支持 Metric/Trace 原生数据模型,Metric 写入到 influxdb,插件可分离,运维控制面协议,自监控、租户数据隔离,DAG based Pipeline,SQL 引擎等计划中。