164.链路诊断最佳实践：1 分钟定位错慢根因

文章目录基于链路及关联数据定位错慢请求异常对象1. 慢请求诊断链路方法栈2. 错请求诊断链路日志异常堆栈/请求参数构建统一实体关系模型1. 分析异常对象真实根因2. 高质量数据领域知识大模型算法智能根因诊断本文聚焦于线上应用的风险管理特别是针对“错”程序运行不符合预期和“慢”性能低下或响应迟缓两大类问题提出了一个系统化的根因诊断方案。线上应用风险主要分为“错”、“慢”两大类。其中“错”的原因通常是程序运行不符合预期比如JVM加载了错误版本的类实例代码运行进入异常分支环境配置错误等。而“慢”的原因通常是资源不足比如突发流量导致CPU飙升数据库大查询导致连接池打满内存泄漏导致持续FGC等等。无论是“错”问题还是“慢”问题。从研发运维视角都希望能够快速止损、定位根因、消除隐患。然而面对复杂的应用间依赖如何抽丝剥茧快速定位异常节点深入分析异常背后的根本原因并在极短的时间完成定位与恢复动作每一步都面临巨大的技术挑战。根据近十年APM领域产品研发与客户支持经验总结沉淀了一套行之有效的错慢请求根因诊断方案主要包括以下几点根据Trace链路及关联数据定位错慢请求异常对象链路追踪可以跟踪一次请求在分布式系统中的流转路径与状态同时将这次请求发生过程中的日志、方法栈、出入参、异常堆栈等数据精准关联实现异常代码行级定位。比如用户在APP下单超时通过前后端链路追踪结合方法栈最终定位到A应用B接口C方法耗时超过3s影响了终端客户体验。根据异常对象关联的实体数据分析真实根因代码执行报错或缓慢只是问题表象导致变化发生的原因可能是一次未经灰度验证的应用发布或是底层基础设施故障亦或是业务流量突增导致共享资源不足。这些信息与异常对象存在着直接或间接的关联关系需要构建更广泛的跨域实体关联才能完成深层次定位。比如A应用正常访问数据库B突然出现许多慢SQL通过数据库客户端与服务端实体关联就能快速定位到数据库服务端连接池打满受到C应用大查询影响。高质量数据领域知识大模型算法实现智能根因诊断线上系统的复杂性决定了根因诊断会涉及海量实体的多模态数据综合分析对于数据丰富度、质量、排查经验与时效性均有极高的要求。构建统一可观测平台实现端到端全栈数据采集遵循一套语义构建统一实体关系模型再结合LLM大模型编排与领域知识库最终实现面向错慢诊断等经典运维场景的自动化归因。基于链路及关联数据定位错慢请求异常对象基于TraceId可以实现请求粒度的轨迹回溯与数据关联。但是错慢请求的诊断流程略有不同慢请求诊断的关键点在于找到真正耗时的代码行。而错请求则分为服务报错与业务报错两类前者依赖异常堆栈后者需要结合业务日志与方法入参进行辅助判断。1. 慢请求诊断链路方法栈慢请求诊断的难点在于如何找到影响总体耗时的关键路径并细化到方法粒度代码行指导研发排障。传统的链路追踪技术都是通过插桩法实现通用接口埋点无法抓取完整的本地方法栈。因此一线开发人员经常遇到定位到慢接口但是不知道内部方法耗时难以优化代码解决隐患。例如阿里云ARMS提供的持续剖析-代码热点功能可以常态化自动抓取慢请求的完整本地方法栈实现行级代码定位大幅提升慢请求定位效率如下所示。根据应用、接口、耗时等参数筛选出满足条件的调用链。查看慢请求分布特征比如是否集中在某一台机器疑似单机故障再展开分析具体的调用链详情。根据调用链瀑布图定位到影响总体耗时的关键服务接口完成问题初步定界。根据代码热点记录的当次慢请求关联的完整本地方法栈直接定位业务异常代码行指导研发同学优化代码。通过以上步骤我们实现了基于链路与关联数据方法栈定位慢请求异常代码行的过程。研发同学拿到慢方法的具体代码行及上下游调用关系就可以通过优化代码逻辑解决慢请求问题。2. 错请求诊断链路日志异常堆栈/请求参数错请求可以分为请求报错与业务报错两类。前者属于程序运行不符合预期比如HTTP 5XX错误抛出RuntimeException。而后者则是业务逻辑不符合预期比如用户下单使用优惠券失败原因可能是优惠券已失效但是服务调用是正常的。针对不同类型的错误排查流程略有差异但关键操作包括以下几类链路与日志双向关联跳转排查系统报错时可以从微服务调用视角找到错误调用链再查看关联的应用日志。而排查业务报错时可以先检索应用日志里的业务关键词再通过日志关联的TraceId反向查询上下游信息。链路关联异常堆栈以Java应用为例系统报错通常会抛出特定异常包含详细的错误原因与调用堆栈通过TraceId准确关联当次请求的异常堆栈可以加速研发排障效率。链路关联请求出入参数不同的请求入参可能会影响程序执行分支比如不同渠道优惠策略有差异。因此在排查一些疑难问题时还需要结合当次请求的方法入参进行判断。而出参由于数据量不可控比如一次数据库大查询返回几万行数据通常只记录ResponseSize而不是完整结果。通过链路与日志、异常堆栈、请求参数等信息的关联我们可以精准识别每一次请求关联的异常信息有效提升错请求诊断效率。构建统一实体关系模型1. 分析异常对象真实根因通过链路及其关联数据我们可以快速定位错慢请求的异常对象但是导致问题发生的真实根因往往更加复杂不局限于应用进程内。为了快速止血或彻底根治我们需要采集更大范围的观测数据并通过统一实体模型构建异常对象与根因之间的联系。最简单最常见的实体关联就是在相同时间范围内同一台主机实例的数据关联。比如A应用部署的某台物理机出现硬件故障故障期间没有及时切流导致路由到该机器的所有流量全部超时报错最终导致业务受损。以Java应用为例ARMS提供了丰富的主机监控数据用以诊断单机问题包括主机/Pod系统指标、JVM GC/堆内存、线程池/连接池等。更广义的实体关联还包括移动终端、网关、数据库、K8S工作负载、CI/CD任务甚至是Git代码提交人。这些跨域实体及其关系最终构建了一张覆盖端到端全栈IT软硬件设施的数据观测网络。任意实体的变化会导致上下游关联实体的联动反应例如A同学执行了一次数据库B实例的索引变更导致C应用出现大量慢SQL进而影响D终端用户下单失败。通过构建统一实体关系模型可以打通跨域数据连接壁垒提升根因诊断效率并为智能诊断打下坚实的基础如下图所示。2. 高质量数据领域知识大模型算法智能根因诊断智能根因诊断不是一个新的概念学术和工业界都有大量的探索与成果但只要技术还在不断迭代线上系统还存在稳定性风险智能根因诊断就是一个历久弥新的课题需要不断进行突破。那么相比以往当下的技术或环境发生了哪些显著变化可以进行哪些新的尝试和探索更大范围更高质量的数据采集随着可观测技术迭代与开源标准的的统一我们可以采集到更加丰富的全栈观测数据比如车机终端、4层网络、系统内核等以OpenTelemetry为代表的可观测数据标准逐步被更多开发者和厂家接受数据孤岛效被逐步破除比如基于W3C标准实现端到端全链路追踪。巧妇难为无米之炊高质量数据就好似新鲜的食材是做成智能根因诊断这道美味佳肴的基础。大语言模型带来的算法革新传统的基于规则的根因诊断难以泛化到通用场景比如慢SQL语法优化。基于概率统计的算法则具有较大的不确定性与算力瓶颈。基于LLM Multi-Agent有希望取得更好的智能诊断效果首先利用大模型可以提升人机交互体验与通用领域问题解答结合RAG运维领域知识库可以解决模型精度或幻觉问题通过Workflow模型编排可以实现整体任务的拆解、剪枝与执行。目前阿里云ARMS已经基于LLM大模型实现了单链路智能诊断综合调用链、方法栈、异常堆栈、SQL、指标等多模态数据结合链路诊断领域专家经验有效识别单次请求的错慢根因并给出相应的优化建议。如下图所示该次请求报错的根因是service-coupon-apm3应用/coupon/coupon/member/list接口内部的queryMemberCoupons方法执行了数据库查询该SQL的WHERE子句使用了空集合作为IN操作符最终导致语法报错。通过Coplilot可以有效提升错慢请求根因诊断效率降低用户诊断门槛。后续会应用到监控告警根因诊断与影响面分析等更多场景。诚然Copilot目前仍面临模型调用耗时长诊断结论输出不够稳定等诸多问题。但是随着更多数据、知识和算法的迭代基于大模型的根因诊断无疑开辟了一条新的智能化之路。