字节跳动观测智能化之路

如果无法正常显示，请先停止浏览器的去广告插件。

1. 字节跳动观测智能化之路服务端观测平台负责人 / 孔罗星

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反馈收集机器人助手数据持久化数据重放触发现场保存 …… 权限&quota管理人工标注准确性回溯

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.