字节跳动超大规模 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 引擎等计划中。
