孔罗星-字节跳动观测智能化之路

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