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

服务端观测平台负责人/孔罗星 个人&团队介绍 Dev Infra-APM/服务端观测平台负责人 13年APM领域经验，21年加入字节后开始负责服务端观测平台 团队面向整个字节内部开发者提供观测平台，与多个团队协同构建Metrics/Traces/Logs/Events等数据埋点&加工链路&存储，并基于此提供一站式的监控、报警、日志、链路追踪、根因分析等产品化能力 What、Why 服务端一站式智能观测平台 业务和架构 现状和挑战 狂奔的业务 用户规模 超大数据量 业务多样性 •微服务数量：数十万•Metrics：数十亿点/s•Traces：近亿Span/s•日志：数百PB存储量•报警：上千万报警规则 •多个业务仍处于快速发展期•技术栈复杂度越来越高：例如AIInfra•业务研发对可观测理解程度不高 •服务整个字节所有业务，包括抖音、懂车帝、飞书、火山引擎、电商等•语言x框架：Java/Go/C++/Pythonx10+框架 •内部用户规模最大的产品之一•数万UV、数十万PV•研发、SRE、QA日常高频使用 •数据需要长期治理•微服务拓扑复杂度高•分析难度大 •业务希望保姆式服务•平台要最大限度降低使用成本•稳定性要求日益提高 •观测数据标准化程度不一•产品体系庞大且复杂•覆盖率提升有瓶颈 •精益求精的产品设计•平台工程整合大量数据&平台•多角色需求不同，导致产品较为复杂 解决思路 双线并行、相辅相成 保持产品演进长期方向，建设好基础能力，同时为AI铺路提高AI投入，通过AI应用降低使用成本，同时辅助用户理解产品设计 AI排障-引入前 手工逐层分析异常指标、Trace、日志，递归查找下游问题 AI排障-引入后 报警即触发全自动分析，自动寻找上下游关联，智能聚合相同根因报警，给出影响面评估 智能化的前置依赖 海量观测数据标准化 日志 •不同对象/组件指标不一致•指标/trace/log不一致•服务/SDK版本不同指标不一致•同类SDK语言不同指标不一致 •人能很容易使用数据吗？•代码或算法容易分析数据吗？•平台内各处容易联动跳转吗? 观测数据标准化：Measurement goruntimev1metrics 指标来源于runtime.MemStats.HeapAlloc,表示当前程序已经申请但尚未被释放的堆内存的总量 metadata goruntimev3metrics metadata 全面且准确的元数据 自动化和智能化的结合 工程架构 自动化分析 智能化排障 对用户而言所谓智能就是原本需要依靠人得出结论的现在能够自动得出了，至于采用的是专家经验还是算法还是大模型用户并不关心，而为了能自动得出结论，我们需要智能算法的帮助 有用>准确 用户心声 •诊断不出来没关系，别误导我！•结果感觉不符合预期，是怎么得出的结论？•原来还可以这么排查，涨姿势了•结果不对，但我看其中的某个图猜到原因了•有的指标从来没关注过，原来这么有用 好处 •极好的可解释性•帮助用户理解如何使用系统•用户亦可贡献经验•用户可抽取部分能力二开 准确率～70% 辅助配套 生态集成 实例迁移 报警卡片 未来展望 极致报警信噪比 01每个服务的报警都需要发给对应的接收人 常常多个服务由一个团队维护，相应的负责人要响应多个报警，且报警有各种类型，但背后可能是一个原因 02多个业务之间互相不知道是同一个问题 是我的问题还是别人的问题？浪费多个团队人力同时都去排查，且根据团队经验不同有可能得出不同结论 03根因服务不知道自己的问题影响有多大 需要详细分析各种指标得出结论，实际情况中由于问题常常叠加，排查难上加难 围绕Problem构建报警 •聚合相同根因的报警，根据接收人的关注点发送通知•根因是什么，是不是我导致的，故障传播链是什么样的•我受到了什么影响、我给别人造成了什么影响 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的延迟偏高，且与服务自身延迟趋势相符，如果想优化性能可关注该服务