字节跳动观测数据埋点标准化实践

来源｜字节跳动基础架构-可观测团队

背景

随着字节跳动业务规模不断扩大，对存量和新增业务的服务质量承诺变得越发关键。稳定性治理方面：怎样支持保障服务线上的高可用性，或者在出现故障/事故时，如何高效且迅速地止损、定位分析影响面已成为一个重要议题。

稳定性建设所涉及的话题十分广泛，涵盖流程梳理与标准化、数据标准化、SLO 定义、故障自愈、事故复盘和演练等方面，字节跳动基础架构可观测团队提供的稳定性平台建设思路是"事前预防、事中处理、事后复盘、事后补救/反哺事前"这四个阶段。

其中，观测数据标准化以及一系列配套的数据链路，如：数据埋点、数据消费、数据存储、数据查询、离线数仓等，都是后续稳定性建设的重要数据基石。

并且，由此引申出排障/止损效率的问题，由于字节的服务/基础设施是分层建设的，包括端侧客户体验层、网络接入层、应用服务层、基础设施层、IDC\资源层等，不同层面的统计/描述口径是否一致、能否对应，以达到在跨层间能上卷下钻和平层内过滤聚合的"车同轨书同文"效果，这对于大幅提升整体排查效率，让 SRE/GOC 同学能够自助完成端到端的问题排查就显得尤为重要。

拥有统一的观测数据标准，能够在很大程度上提升团队间的排障效率，从人工分析的方式提升至更大程度的自助/自动化排障的阶段。

埋点标准化的重要性

提高研发效率 & 降低研发协同成本

面向排障方面：跨层间的上下文过滤便捷，术语统一。
进行历史数仓分析（容量优化）时，整体数据处理逻辑的适配成本会大幅降低。
用户的学习曲线陡峭，理解心智负担沉重。

为 AIOps 提供强有力的数据支撑

观测数据属于 AIOps 的五大基石（数据、知识、算法、代码联动、人机协同）之一。在清华裴丹老师的《AIOps 落地的 15 条原则》里，也都提及了数据的重要性。

拥有数据标准化和统一的访问体验，为后续稳定性的终极目标 MTTR 1-5-10（1 分钟发现，5 分钟响应以及 10 分钟快恢复）提供了数据层面的保障。包括同层数据的聚合 / 过滤，以及跨层数据的下钻和上卷，都会有统一的使用方式。

名词解释

名词	解释
Metrics 2.0	字节跳动内部使用广泛的时序数据处理引擎，提供了时序数据收集、存储和聚合查询的功能。2.0 版本提供引入多值概念，打平prometheus 4类指标类型语义、支持秒级打点& 存储周期定制化等多租户特性、端到端高性能优化的分布式时序集群版本。
BytedTrace	BytedTrace是字节跳动使用的一套集成了 Tracing/Logging/Metrics 三种能力的可观测性解决方案，提供了从采集、传输、存储、检索到前端产品化交互的整套能力。它定义了统一的数据模型（Trace 、Span 、Event、Metrics 等），提供了各语言配套 SDK，并与公司各主流框架组件实现默认集成。
观测埋点 TagKV	Metrics TagKV 是一种用于标记和管理度量数据的键值对（Key-Value Pair）格式。通常用于监控系统、分布式追踪系统和日志管理系统等领域，TagKV 提供了一种灵活且高效的方法来分类和筛选数据。
Measurement	可观测对象的某个指标，如服务的上游调用延时，物理机的 CPU 使用率。Measurement 是带有可观测对象的 context的，是语义化的，同时能识别在不同条件下应该使用哪个版本的指标以及对应的 TagKV。而且可以根据观测对象的元数据条件，同时关联多个时序数据源，便于按需时序数据源切换。
SLO	Service Level Objectives，服务级目标是指服务提供方对所提供服务的某些性能或质量指标所设定的目标值。这些指标通常用于衡量服务的可用性、性能和其他关键属性，旨在确保服务达到预期的质量水平。
TCE	Toutiao Cloud Engine，为字节跳动内部提供的高度可用、弹性扩展的容器服务。
PSM	Product Subsys Module，是字节跳动内部服务的唯一标识。
GOC	Global Operations Center，基于字节跳动各类研发，运维体系下的高可用产品能力，结合稳定性保障策略及运营机制，提供字节跳动全线基础产品的可靠性服务与设施稳定性保障，达成字节跳动全线业务各类场景下的端到端高可用性。

字节埋点标准化挑战与拆解思路

挑战：历史上可观测性埋点质量偏低

首先，我们对埋点标准化进行定义，包括但不仅限于如下的标准定义，包括覆盖完整、定义统一、计量准确、面向引擎友好等四大方面。

简而言之，在 2020 年以前，从覆盖完整 、定义统一 、计量准确 、面向引擎友好等维度来看，字节整体的观测数据埋点存在一定的差距。

具体如下：

负载均衡埋点
- 计量准确：中等水平
  - 存在较严重的打点丢失问题
- 面向引擎友好：较低水平
  - 指标打点对于配置预计算不友好
  - 指标名膨胀也比较严重
微服务埋点
- 覆盖完整：中等水平
  - 20 年前 Tracing 方案还在 V1 版本
- 计量准确：中等水平
  - 遇到高基数的指标会被封禁
- 面向引擎友好：较低水平
  - 指标打点对于配置预计算不友好
  - 指标名膨胀也比较严重
  - 加权计算也不好实现
语言运行时埋点
- 定义统一：较低水平
  - Golang & C++ 框架不同的版本定义的指标格式都不太一样
- 面向引擎友好：较低水平
  - 指标打点对于配置预计算不友好
容器指标埋点
- 覆盖完整：较低水平
  - 没有日志采集覆盖
- 计量准确：中等水平
  - 遇到高基数的指标会被封禁
- 面向引擎友好：较低水平
  - 指标打点对于配置预计算不友好
基础架构存储 & 数据库埋点
- 覆盖完整：较低水平
  - 存储、数据库、MQ 客户端没有黄金指标打点
  - 没有日志采集覆盖
- 计量准确：较低水平
  - 不同存储、数据库、MQ 产品打点格式都不一
- 面向引擎友好：较低水平
  - 指标打点对于配置预计算不友好

思路：分层&向后兼容推进埋点标准化

总结来说，之前的字节服务端观测数据质量大致存在三类问题。

同层数据/跨层数据不一致。
观测的多模态数据类型（指标、日志、链路）的数据定义不统一。
观测数据格式对引擎不够友好，例如所有数据都在 default 租户的一个大仓里，再比如很多观测指标的定义对于预计算不友好。

针对上述问题，我们采取了如下的多个思路逐一进行解决。

实施思路

一方面，在埋点侧就尽可能统一埋点 TagKV 定义，而且平台级 TagKV 都通过环境变量或者请求上下文自动注入对应的 Tag Value，以防止由业务手工注入带来的人工错误。

另一方面，对于指标、链路和日志侵入式 SDK，我们通过字节内部的远程过程调用框架以及存储、数据库、消息中间件的客户端 SDK 搭载嵌入中间件，对于业务来说，能相对透明地升级到最新特性的版本。另外，对于远远低于 SDK 基线版本的服务，我们也通过字节软件供应链安全治理平台通过编译卡点的不同程度[warning 提示/发布卡点]推动业务升级。

在负载均衡、应用、中间件、存储计算组件等各个纵向方面，我们也主动与对应的平台对接，推动指标、日志、链路的埋点注入。

最后，在指标埋点上也额外关注对于多租户的声明，以达到一定的分库分表功能，以及多值声明，以最大程度减少数据消费和存储成本。如下所示，就是团队在各个不同观测对象的埋点方面所做的业务推进情况。

难点：识别和解决

类似观测数据标准化的工作历经多年，牵涉的团队众多，整个过程并非毫无波折。遇到问题时要解决问题并思考能否将其标准化或者平台化，同时也要考虑能否尽可能地复用其他团队的能力和工具来助力我们进一步推广。当时如何高效地推动业务升级是我们的主要目标。

[业务推进] 高效推动业务升级观测SDK

在 Metrics SDK 需要升级到基线版本的情况下，以前的做法是在字节软件供应链安全治理平台上配置版本拦截，提醒用户升级，但是整体升级效率比较低，我们也无法跟踪用户的升级进展。因此我们联合字节软件供应链安全治理平台团队实现 SDK 自动升级功能。

Metrics ****SDK 自动升级

Metrics ****SDK 自动升级功能可以自动实现在当前业务代码库的代码提交期间，如果检测到对应集成的metrics SDK 低于基线版本，则会向用户推送代码提交失败的通知，提醒用户需要主动升级到metrics SDK基线版本或以上的操作。

远程过程调用 框架 & 基础组件客户端 集成 ****BytedTrace ****SDK 集成

观测团队多年来持续推动公司的远程过程调用框架以及基础组件客户端集成 BytedTrace SDK ****。 ****借助字节软件供应链安全治理平台进行递进式卡点推广，依靠代码血缘平台来推动框架、组件的基础库版本实现升级。在存有流量的微服务上，BytedTrace SDK的覆盖比例按照 TCE pod 接入情况来计算，当前已达到 95%。

从服务的优先级角度而言，公司当前96% 的 P0 服务中已接入 Bytedtrace SDK 。

[业务推进] 提升基础组件观测埋点质量

TCE 调度 / 运行时 打点格式设计思路

前文提到，提升业务层、应用层、容器层等多层间指标的跨层关联和下钻能力是指标标准化的一个重要目标，而实现跨层关联的关键动作在于保证同一含义的指标 TagKV 在各层上的定义保持统一，为实现这一点，我们对各个层次上的核心组件进行了统一的设计，具体如下：

层次	核心组件/着手点	埋点标准化设计思路
业务层	Metrics 2.0 SDK	- 内置统一的平台级TagKV，提供横向跨语言、跨服务的TagKV统一
应用层	运行时指标、远程过程调用指标	- 横向上，提供统一的、跨语言的指标名定义

纵向上，对齐Metrics 2.0 SDK 平台级TagKV规范 | | 容器层 | 与调度合作，对容器指标采集agent(TCE调度)进行标准化改造 | - 对齐Metrics 2.0 SDK 平台级TagKV规范 |

首先，我们在 Metrics 2.0 SDK 内置定义了一套平台级 TagKV，这样所有使用 Metrics 2.0 SDK 的业务打点都会携带标准的预定义的 TagKV。这些共同TagKV包括： _cluster、_psm、_pod_name、_ipv4 等。
在应用层，挑选了对业务排障、应用观测常用且通用的两类指标（运行时、远程过程调用）进行标准化，目标是在横向上，提供跨语言、统一的指标名、TagKV语义定义等；在纵向上，对齐 Metrics 2.0 SDK 平台级 TagKV 规范，以便于跨层关联。以运行时指标为例，其定义规范如下：
1. 不同语言的指标采用统一命名约定：runtime. {runtime} . {metric}[ . {field}]
2. 不同语言类似含义指标采用统一命名风格：如 go、java 中统计堆对象申请量的指标都命名为memory.allocated_bytes
3. 必须包含 Metrics 2.0 SDK TagKV 规范的平台级 TagKV，如 _psm、_pod_name 等
在容器层，与调度团队共同推动其 TCE 容器指标采集 agent(TCE调度) 的指标标准化改造，指标 TagKV 对齐Metrics 2.0 SDK TagKV 规范。

通过将这些核心组件进行标准化改造，为跨层的指标关联和下钻提供了能力基础。同时，在每个核心组件的指标定义上，我们还通过以下两个方式进一步提升埋点的性能和成本收益，第一点是对各个组件使用独立租户，实现资源的隔离，保障写入稳定性和查询性能；

指标	租户名	集群类型
运行时	apm.runtime	独立集群
远程过程调用框架	apm.rpc	独立集群
TCE 容器指标	computation.tce	独立集群

第二点是在语义明确的前提下，尽量使用多值格式定义指标，降低存储成本。以 TCE调度指标为例，将原来 mem 相关的四个指标合并为一个多值指标的四个字段，存储成本大致可以被认为降低至四分之一。

原指标	改造后多值指标名	改造后多值字段
tce.host.mem_total	inf.tce.host.mem	total
tce.host.mem_free	free
tce.host.mem_available	available
tce.host.mem_used	used

[配套工具] 帮助平滑迁移观测数据

[工具1] 语义化指标替换

我们提供语义化指标替换，称为Measurement，其能力就是对原始 Metrics 打点的语义化封装；同时能识别在不同条件下应该使用哪个版本的指标以及对应的 TagKV。这两个关键能力能够促使在做数据迁移时，观测大盘和报警基本达到比较平滑的状态。

原始 Metrics 打点：直接写入时序数据库（可以是 metrics \ influxdb \ prometheus）的数据。

语义化封装：用标准的语义化来包装原始的 metrics 打点数据。比如 go 服务的 gc 数量的 metrics 打点是 go.{{.psm}}.numGcs，其中{{.psm}}为具体的 psm，我们会定制一个语义化指标名叫 "runtime.go.gc_num"来表达 go 服务的 gc 数量，包括用统一的 TagKV 来封装对应的原始 TagKV。不管是 open api 还是前端调用，都用指标 "runtime.go.gc_num" 对measurement 服务进行调用。

不同条件下的查询 路由：需要这个能力是因为在字节内部原始 Metrics 的打点会不断的升级，比如 golang 运行时历史上会有 v1 、v2 、v3 多个版本，我们需要能够在给定的输入信息条件下去查询到对应的指标版本。这个判断条件实现的逻辑一般为可用输入的 psm 名字构成 Metrics go v1 的指标名，再根据指标名的数据是否存在来判断是 runtime v1、runtime v2 或者 runtime v3 的版本，指标判断也以此类推。或者可以通过 psm 的 scm 编译信息确定该 psm 编译的 golang 运行时版本是 v1、v2 或者 v3。通过对应条件的判断来做到对应数据的查询路由。

在有了 Measurement 能力后，我们抽象出了 Measurement 服务，该服务作为观测大盘和报警的一个数据源。在尽量不需要用户介入的情况下完成数据打点的迁移和替换。

当前借助 Measurement 能力，针对公司的远程过程调用、HTTP 等框架，容器引擎、FaaS、机器学习推理等平台，还有负载均衡、缓存、数据库、消息队列等基础组件，以及golang 运行时等，均进行了统一的标准化语义封装，这些语义化封装在观测平台上均有所展现。

[工具2] Metrics 前缀分流

怎样帮助业务顺利地迁移到新租户，同时确保新老指标的查询方式均可使用，是我们在推动业务租户迁移时所面临的较大挑战。

针对上述问题，观测团队起初推进引导用户主动迁移至新租户，旨在实现租户隔离，提供更优的稳定性保障，进行精细化容量治理以降低成本。然而，后来发现主动迁移的速度太慢，赶不上打点量的自然增长。于是，推出了让用户无感知的被动租户迁移方案。大致思路是依据某些特定的指标前缀，主要涵盖一级 / 二级前缀，通过特定配置把这些指标分别路由到不同的新租户，并且在新租户上支持查询翻译，即便用户不修改查询租户，继续用 Default 租户查询仍能正常获取数据。该方案具有以下优势：

业务在读写两侧无需进行代码变更，就能将流量迁移到新租户集群。
最大程度减少不同租户间因集群变更和读写流量变化对线上稳定性产生的相互影响，提供更出色的稳定性保障。
精准对接业务线租户，便于后续进行打点流量治理、容量规划以及资源充值等操作。

具体的实现由 Metrics 组件中各模块的相互配合完成，包括写入、控制面、查询、数仓等方面，大致的实现流程如下：

前缀分流租户的整个过程存在众多细节，为减少过程中的过多人为操作，防止出现某些环节被遗忘的情况，观测团队设计了分流流程工单以及白屏化运维平台，尽可能让整个操作流程实现自动化，提高分流租户的效率。此外，前缀分流迁移新租户的整个过程对于业务来说成本为零，同时对于观测团队而言不像依赖业务方主动迁移那样周期漫长，其周期短、生效时间快，能够收敛团队人力的持续投入。

总的来说，观测团队提供了一种让用户无感知、实现无缝迁移新租户的方案，用户的核心观测大盘和报警也无需修改，最大程度降低了埋点标准化对用户的打扰。

埋点标准化字节的实践与效果

观测数据质量前后对比

经过 2020-2022 年推进 BytedTrace SDK 覆盖率、2023 年推动云基础组件和应用层指标租户迁移之后，从埋点标准化的 4 个维度看，都有不同程度的质量提升。

负载均衡
- 计量准确：较高水平 [2020年为中等水平]
  - 通过 2.0 SDK 三个特性，基本消除丢点的问题：
    - 打点本地聚合
    - 面向字节流的 codec 编码
    - Agentless 投递
- 面向引擎友好：较高水平 [2020年为较低水平]
  - 实现面向预计算友好的效果
- 成本收益：
  - Metrics 2. 0 打点商品成本相对 1.0 下降 94%
  - Metrics 2. 0 很好地解决了打点封禁问题，特别是在一些配置量巨大的核心集群，解决了其超过 90%打点无法查询的情况
  - Metrics2. 0 TLB 机器成本初步统计主容器和 adaptor 打平，同时相对 1.0 节约了 ms2 的 15000 核资源
微服务
- 覆盖完整：较高水平 [2020年为中等水平]
  - 80%以上 PSM 覆盖到 BytedTrace SDK 集成
- 计量准确：中等偏上水平 [2020年为中等水平]
  - 高基数的指标封禁问题由于迁移到了新租户可以做封禁阈值定制化
  - [计划中] 升级 bytedTrace 内的 metrics 2.0 SDK 降低丢点的风险
- 面向引擎友好：较高水平 [2020年为较低水平]
  - 实现面向预计算友好的效果
- 成本收益：
  - 以计算关键组件 Consumer 为例，新租户只需要老租户 20%的资源，就可以完成相同数据的写入计算；其他写入计算类组件也类似
  - 以存储关键组件 tsdc 为例，新租户只需要老租户 55%的资源，就可以完成数据的写入、存储
语言运行时
- 定义统一：较高水平 [2020年为较低水平]
  - 统一了不同语言和框架的运行时打点格式
容器指标
- 覆盖完整：中等水平 [2020年为较低水平]
  - TCE调度接入日志租户
- 计量准确：较高水平 [2020年为中等水平]
  - 引入多值降低指标名数量
  - 高基数的指标封禁问题由于迁移到了新租户可以做封禁阈值定制化
  - 通过 2.0 SDK 三个特性，基本消除丢点的问题
    - 打点本地聚合
    - 面向字节流的 codec 编码
    - Agentless 投递
- 面向引擎友好：较高水平 [2020年为较低水平]
  - 实现面向预计算友好的效果
基础架构存储 & 数据库
- 计量准确：较高水平 [2020年为中等水平]
  - 引入多值降低指标名数量
  - 高基数的指标封禁问题由于迁移到了新租户可以做封禁阈值定制化
  - 通过 2.0 SDK 三个特性，基本消除丢点的问题
    - 打点本地聚合
    - 面向字节流的 codec 编码
- 面向引擎友好：中等水平 [2020年为较低水平]
  - 打点格式调整的支持预计算配置
- 成本收益：
  - 以 mysql 迁移为例
    - Mysql 租户成本节省 45.7%
    - Mysql 租户带宽节省了 80%

截止到今年年初， Metrics 在中国国内区域已经接入 60+ 租户，占总流量的 70% 左右。

赋能效果总结

加速微服务端到端根因定位

通过指标标准化 & 多模观测数据 [指标，日志，链路]标签术语的标准化，我们实现面向微服务的上卷 & 下钻关联分析。

也使得使得跨层问题根因分析有了可能性：

目前端到端根因定位覆盖了60%以上的报警场景，日均触发根因定位 50余万次，用户对定位结果的正反馈率超过80%。

简化服务性能离线数仓构建

在实现了在线观测数据的标准化，并将其导入统一的存储介质之后，构建字节整体关于服务性能、容量、吞吐量的数仓大盘就更加便捷。比如展现某服务的单核 QPS 分时热力图如下:

目前基于微服务应用性能数仓已覆盖公司超97%的微服务量化，有效支持字节跳动各业务线服务性能、服务应用健康度度量，由此带动一系列精准的成本优化。

观测底座自身收益

从稳定性角度看，由于引入metrics多租户概念，所以我们能够通过逻辑租户映射到物理资源，从而降低故障半径，减少不同租户间流量的相互干扰。
从成本角度看，我们能够依据每个租户的副本数、存储时长 TTL、打点的最小精度以及多值定义，最大程度地降低写入流量和存储容量的成本。metrics 多租户迁移前后对比，成本节省幅度在 20% ~ 80% 不等。

总结

历经上述观测埋点套件 BytedTrace SDK推广、Metrics 指标标准化迁移和推广、部分业务接入日志多租户，字节后端观测数据的质量在覆盖完整度 、定义统一 、计量准确 、面向引擎友好四个方面上取得了显著的质量提升。这也为后续的全景全栈高效排障奠定了坚实的基础，帮助更多业务团队在业务稳定性方向持续建设。

依托字节跳动内部可观测团队大规模技术实践，通过内外合力，在火山引擎上推出了应用性能监控全链路版（APMPlus）、托管 Prometheus（VMP）、云监控等可观测产品，致力于为用户提供全面、智能、高效、易用且安全的全栈可观测解决方案。

目前 APMPlus Server 端监控已正式 GA 并支持最新的大模型链路追踪相关能力，欢迎咨询了解。

🔗 相关链接

APMPlus ： www.volcengine.com/product/apm...

VMP ： www.volcengine.com/product/pro...

云监控 ： www.volcengine.com/product/clo...