字节跳动观测智能化之路
如果无法正常显示，请先停止浏览器的去广告插件。
1. 字节跳动观测智能化之路
服务端观测平台负责人 / 孔罗星
2.
3. 个人&团队介绍
Dev Infra-APM / 服务端观测平台负责人
13年APM领域经验，21年加入字节后开始负责服务端观测平台
团队面向整个字节内部开发者提供观测平台，与多个团队协同构建
Metrics/Traces/Logs/Events等数据埋点&加工链路&存储，并基于此提
供一站式的监控、报警、日志、链路追踪、根因分析等产品化能力
4. What、Why
服务端一站式智能观测平台
5. 业务和架构
服务场景
日常排障、性能分析
架构治理优化
配合团队
稳定性、容灾、大促
成本优化
Kitex
平台功能
监控
日志
报警
APM as a Service
Trace
Hertz
Jet RPC
微服务/基础设施/SLO 聚类分析 报警统计 高级分析 内置应用 生态集成
数据探索 日志加工 Duty引擎 查询检索 LLM Agent Case管理
标准指标
Measurement 查询检索 报警引擎 采样策略
开放平台：观测数据、元数据、算法、workflow
Mesh
TCE(容器)
FaaS
组件(Redis/MySQL…)
元数据
服务元数据
组件元数据
SYS-STE(物理层)
拓扑关系
语言团队
观测数据
Metrics
Logs
Traces
…
Profilings
Events
6. 现状和挑战
用户规模
• 内部用户规模最大的产品之一
• 数万UV、数十万PV
• 研发、SRE、QA日常高频使用
超大数据量
• 微服务数量：数十万
• Metrics：数十亿点/s
• Traces：近亿Span/s
• 日志：数百PB存储量
• 报警：上千万报警规则
狂奔的业务
业务多样性
•
•
服务整个字节所有业务，包括抖音、懂 • 多个业务仍处于快速发展期
车帝、飞书、火山引擎、电商等 • 技术栈复杂度越来越高：例如AI Infra
语言x框架：Java/Go/C++/Python x • 业务研发对可观测理解程度不高
10+框架
• 精益求精的产品设计 • 数据需要长期治理 • 观测数据标准化程度不一 • 业务希望保姆式服务
• 平台工程整合大量数据&平台 • 微服务拓扑复杂度高 • 产品体系庞大且复杂 • 平台要最大限度降低使用成本
• 多角色需求不同，导致产品较为复杂 • 分析难度大 • 覆盖率提升有瓶颈 • 稳定性要求日益提高
7. 解决思路
双线并行、相辅相成
保持产品演进长期方向，建设好基础能力，同时为AI铺路
提高AI投入，通过AI应用降低使用成本，同时辅助用户理解产品设计
产品演进 数据标准 覆盖度 平台能力 场景化应用
抄近路 - AIOps 自动化 智能化 内置RCA 各处集成
8. AI排障-引入前
手工逐层分析异常指标、Trace、日志，递归查找下游问题
9. AI排障-引入后
报警即触发全自动分析，自动寻找上下游关联，智能聚合相同根因报警，给出影响面评估
10. 智能化的前置依赖
11. 海量观测数据标准化
MySQ
L A
Servic
e B
Servic
e A
Redis
A
Servic
e C
container.cpu.usage
jvm.heap.usage
rpc.client.latency Service A
go.runtime.coroutine_cnt Container
…
Process
Host 1
CPU
Runtime 内存
Rpc client 磁盘IO
Rpc server 网络
… 内核
MySQL A
Proxy Data Server
Container Container
… …
12. 不规范的Metrics tag举例
机房
ipv4地址
服务集群
pod name
_dc
host
cluster
podname
dc
ipv4
paas_cluster
_pod_name
idc
hostv4
cluster_name
pod_name
日志
• 不同对象/组件指标不一致
• 指标/trace/log不一致
• 服务/SDK版本不同指标不一致
• 同类SDK语言不同指标不一致
• 人能很容易使用数据吗？
• 代码或算法容易分析数据吗？
• 平台内各处容易联动跳转吗?
13. go runtime v1 metrics
观测数据标准化：Measurement
go.{{.psm}}.heap.byte
go.{{.psm}}.gcPause.us
指标来源于 runtime.MemStats.HeapAlloc, 表
go.{{.psm}}.numGos
示当前程序已经申请但尚未被释放的堆内存的总
metadata
量
language=go
用户
runtime_sdk_version=1.3.1
framework=kitex
service.runtime.go.total_bytes
指标描述
service.runtime.go.gc_pause
tag映射
service B
service.runtime.go.goroutine_num
路由规则
go runtime v3 metrics
runtime.go.memory.allocated_bytes{psm=xyz}
runtime.go.gc{psm=xyz}
_dc = dc
_pod_name = pod_name
runtime.go.goroutine.num{psm=xyz}
if runtime_sdk_version >= 3.0.0
use runtime v3 metrics
metadata
else
language=go
runtime_sdk_version=3.1.1
framework=kitex
use runtime v1 metrics
cluster_name = cluster
14. 全面且准确的元数据
MySQL是什么
版本？是否分
片？
B是A的强依赖
还是弱依赖？
MySQ
L A
A是什么语言的
服务
版本是多少？
Servic
e B
Servic
e A
Redis
A
MySQL A
Proxy Data Server
Container Container
… …
Servic
e C
container.cpu.usage
jvm.heap.usage
rpc.client.latency Service A
go.runtime.coroutine_cnt Container
…
Process
Host 1
CPU
Runtime 内存
Rpc client 磁盘IO
Rpc server 网络
… 内核
如何得到容器的
宿主机？
只知道宿主机
IP，它在哪个机
房？是什么规
格？
• 微服务元数据
• 组件元数据
• 拓扑元数据
• …
易分析的数据 = 观测数据 join 元数据
15. 自动化和智能化的结合
16. 工程架构
智能归因整体架构
内置应用
RCA
平台集成
监控图表
Problem
报警卡片
业务自定义RCA
飞书机器人
框架基建
观测数据、元数据、算
法SDK
分析套件
业务指标分析
风险巡检
Case管理
编排框架
FaaS集成
用户反馈、根因标注
数据持久化
准确率回溯
LLM
Agent
元数据
服务技术栈
组件元数据
拓扑关系
观测数据
Metrics
Logs
Traces
Profilings
Change Events
Alert Events
17. 自动化分析
分层API
分析错误类型
可用性下降分析
递归分析上游
MySQL异常分析
维度下钻
是否上游问题
High-Level
局部性问题剪枝
延迟上涨分析
关联分析
…
根因选择
单实例分析
获取因果关系静态表
排列组合
过载分析
Mid-Level
流量来源分析
分析动态因果关系
Panic分析
专家经验
…
数据访问
Low-Level
原子算法
数据
算法
筛选最终根因
是否下游问题
递归分析下游
18. 智能化排障
对用户而言所谓智能就是原本需要依靠人得出
结论的现在能够自动得出了，至于采用的是
报警触发
专家经验还是算法还是大模型用户并不关心，
而为了能 自动 得出结论，我们需要智能算法的帮助
飞书卡片
根因分析
相同根因
Problem
Problem
19. 有用 > 准确
用户心声
• 诊断不出来没关系，别误导我！
结论+过程
• 结果感觉不符合预期，是怎么得出的结论？
• 原来还可以这么排查，涨姿势了
• 结果不对，但我看其中的某个图猜到原因了
• 有的指标从来没关注过，原来这么有用
好处
• 极好的可解释性
用户反馈有用率 > 90%
准确率 ～ 70%
• 帮助用户理解如何使用系统
• 用户亦可贡献经验
• 用户可抽取部分能力二开
20. 辅助配套
Case反馈收集 机器人助手 数据持久化
数据重放 触发现场保存 ……
权限"a管理
人工标注
准确性回溯
21. 生态集成
监控大盘
实例迁移
webhook
飞书
报警卡片
22. 未来展望
23. 极致报警信噪比
SRE
开发
开发
直播
开发
交易
本地生活
中台
电商SRE
A服务开发
B服务开发
中台服务开发
宿主机
24. 01
每个服务的报警都需要发给对应的接收人
常常多个服务由一个团队维护，相应的负责人要响应多个报警，
且报警有各种类型，但背后可能是一个原因
02
多个业务之间互相不知道是同一个问题
是我的问题还是别人的问题？浪费多个团队人力同时都去排查，
且根据团队经验不同有可能得出不同结论
03
根因服务不知道自己的问题影响有多大
需要详细分析各种指标得出结论，实际情况中由于问题常常叠
加，排查难上加难
围绕Problem构建报警
• 聚合相同根因的报警，根据接收人的关注点发送通知
• 根因是什么，是不是我导致的，故障传播链是什么样的
• 我受到了什么影响、我给别人造成了什么影响
25. SRE
B团队
直播
B团队
交易
本地生活
中台
电商SRE
A团队
中台服务开发
宿主机
26. LLM & Bot Studio
27. LLM & Bot Studio
Bot Studio能做什么？
插件：对接外部数据，例如自己开发的API
知识库：沉淀知识，通过各类数据源抓取
工作流：自定义开发，编排插件、代码处理等
发布：发布成飞书、微信等bot，同时也可以发布API
自动化编排：根据用户输入自动调用插件、知识库、工作流
可观测性&运维场景Case
插件：对接RCA分析API
知识库：录入指标规则、报警规则等
工作流：对API做包装，例如转换时间格式、默认值填充
发布：飞书bot、API提供产品调用
运维诊断非常定制化，需要有编排能力
通过Bot Studio使开发过程极大简化，可充分利用大模型能力
插件+工作流提供了足够的拓展空间，让各种可观测和运维能力tools可以轻松集成
Low/Mid/High Level API都可以被整合，按需调用自由编排
28. AI Everywhere
报警规则解读
服务巡检
More
各类数据分析
我的服务有什么需要关注的地方吗
统计服务过去一天的SLO达标情况
学习产品功能
大盘图表太多找不到关注点？
您的服务在过去一周运行整体正常，但存
解读日志内容
在部分稳定性风险：
1. CPU使用率在每日10:00 – 11：00
报警噪音过大该如何优化？
较高，有过载风险[查看详情]，请考虑
生成图表大盘
扩容。扩容N台可将CPU使用率降低
至60%以下
服务性能热点在哪里，该如何优化？
通用知识问答
2. 有2个下游调用错误率持续较高，但没
有影响服务可用性(是弱依赖)，查看详
情
我的日志是否有隐私泄露风险？
3. 调用下游A的延迟偏高，且与服务自身
自动化排障
延迟趋势相符，如果想优化性能可关
注该服务
某个指标是啥含义？
……
自动化运维
任何需要自动化、智能
化的地方
29.