《1-付求爱-服务性能分析探索与实践.pdf》由会员分享,可在线阅读,更多相关《1-付求爱-服务性能分析探索与实践.pdf(42页珍藏版)》请在三个皮匠报告上搜索。
1、服务性能分析探索与实践时间:2023/05/12作者:华为云 付求爱2023 深圳站付求爱多年AIOps智能运维行业经验,担任华为云智能化运维算法专家、PaaS技术创新La智能化运维业务负责人,负责华为云PaaS研发质量看护和智能化运维关键能力构建、技术研究、整体规划、团队管理及交付落地。华为云 智能化运维算法专家嘉宾照片2023 深圳站目录CONTENTS背景介绍01 面临的挑战02 现有技术分析03 方案介绍04 有益效果05 总结06 2023 深圳站背景介绍2023 深圳站背景介绍现如今,微服务架构在部署、扩展以及自动化等方面相比传统架构都具有明显的优势,越来越多的系统选择采用微服务架
2、构。2023 深圳站背景介绍当微服务系统发生故障或性能下降时,定位问题根因是非常困难的。在微服务系统中,一个用户请求需要众多服务通过相互调用的方式共同实现,这些实现同一个用户请求的调用被称为一个调用链;调用链有时候是非常复杂的。2023 深圳站背景介绍当性能问题发生时,真正有问题的服务和与它相关的服务,都会出现指标异常以及发出告警;大量的告警让运维人员无法确定哪个微服务及接口才是故障根因。只能逐个去排查,排除掉那些本身并没有异常的服务。对于中大型系统而言,不同的服务是由不同的运维人员甚至不同的部门管理的,因此问题定界定位分析涉及到不同人员甚至不同部门的合作,分析成本非常高。因此,自动化的高效率
3、的性能分析服务对于快速处理基于服务的系统性能故障是非常重要的。2023 深圳站华为云真实案例根因接口特征:接口响应时长排第二调用次数相比其他接口调用次数偏大故障期间接口调用次数相比日常量变化不大现网大概50几个接口出现同步响应时间陡增影响现网用户100+,牵扯3个实体组织共12人,耗费1.5小时定位出问题2023 深圳站接口时延排名第一的原因为连接数据库时间过长2023 深圳站接口时延排名第二的原因为出现慢查询SQL(根因接口)2023 深圳站排名第三接口出现一条慢SQL和数据库连接池时间过长2023 深圳站面临的挑战2023 深圳站挑战 1服务间依赖关系复杂,难以分析性能问题在服务之间的传递
4、挑战 2服务更新迭代频率高,线上的云服务往往需要按需/按日发布版本,导致特征提取困难挑战 3性能异常跨调用链传播,要有跨调用链的共因识别能力,排除假阳性面临的挑战2023 深圳站现有技术分析2023 深圳站 基于长尾任务的性能恶化分析主要缺点:只认为根因会发生在耗时最长的一条恶化调用链中,容易将真实根因排除掉;只考虑服务的耗时情况,没有考虑异常传播问题,导致分析不全面;仅能识别耗时相关问题,对调用链结构异常、参数错误等导致的性能问题不具备识别能力。检测服务性能恶化遍历恶化时间窗口内,服务被调用的N个调用链选耗时最长的调用链对这条耗时最长的调用链做根因分析(基于耗时主导因素)认为得到的根因是整个
5、服务的恶化根因2023 深圳站 基于单调用链模板匹配的性能恶化分析检测服务性能恶化预处理:获取恶化时间窗口内同一接口的成功调用,并聚类形成调用链模板处理待预测调用:对带预测调用链进行基于模板的根因分析根据相似度匹配最佳模板输出性能恶化根因与模板调用链进行比较,保存差异对于模板调用链的差异进行根因分析从历史成功调用链数据中提炼正常调用链模板,对于每个分析对象,匹配最佳模板,再进行差异分析,最后排序推荐根因。主要缺点:仅着眼于根因在单条调用链上的影响因素,忽略了故障在调用链之间的相互影响以及调用链之间的差异;仅能在单条调用链上推荐根因,无法上升到真实场景中更常见的接口粒度根因推荐;无法识别多根因场
6、景。2023 深圳站 基于恶化传播图的性能恶化分析开始结束服务是否发生性能恶化?服务KPI数据通过AD算法检测服务的KPI数据构建恶化传播图节点KPI是否异常存储微服务KPI变更时间点及数据,触发基于随机游走的性能恶化根因分析方法YNNY主要缺点:对于一处异常而言,仅在得到的故障传播图上进行考虑,利用的信息不充分;该方法仍是基于传统随机游走的算法,基于随机游走的方法都存在一个缺陷,即当系统中同时出现多个故障时,服务可能会受到叠加影响,而导致分析的准确性下降。2023 深圳站方案介绍2023 深圳站服务性能恶化检测及定界方案特点1:使用基于历史数据(7天)的机器学习方法,独立学习待分析服务每个接
7、口在3个不同维度上的习惯性特征,相比于手工设置的阈值,自适应性更强,且无需人工打标异常检测(AD)性能更好。特点2:使用Top-3推荐准确率作为最终的性能问题定界能力衡量标准,以缩小接口范围作为定界目标,保证根因接口不会被漏报。2023 深圳站异常检测(AD)算法说明stationaryseasonalNon-stationarySigmaADPeriodADDifferentiateAD平稳数据(绝大部分)周期数据(少部分)非平稳数据(少部分)从周期性、稳定性和自相关性等多维度对数据进行特征提取,并根据提取出来的特征选择最优的检测器。针对不同的服务场景选择对应的算法,得到更准确的结果。202
8、3 深圳站服务性能恶化定位方案主要目标:基于单接口根因分析算法确定异常值比较高的前N个接口的根因,并利用根因自底向上的归纳和反推N个接口中的Top-3根因接口。2023 深圳站单接口恶化根因定位方法数据驱动下自动化提取调用链参数级正常模式,识别调用链异常点推荐潜在根因历史上正常执行的n次调用链模块1:离线训练单接口的调用链正常模式数据预处理有向图表示分支模板周期性更新正常模式库调用链聚类识别不同分支提取序列与参数级模板模块2:在线定位该接口问题根因对推荐根因进行评分、排序多维评价候选根因(2)对异常多调用链候选根因进行汇聚,得到最终根因链上分数计算链间分数计算拓扑分数计算三个规则排序考虑耗时和
9、波动剔除逻辑下游计算最终得分异常单调用链数据预处理分支匹配单调用链候选根因调用链模式差异对比时延差异参数差异结构差异(1)获取单调用链候选根因2023 深圳站面临的挑战&多根因汇聚首先对单条调用链进行分析,获取链上得分,并推荐出链上候选根因调用链根因定位的两个棘手难题:故障可能跨调用链传播,因此要有跨调用链的共因识别能力,排除假阳性。服务之间依赖关系复杂,不仅要考虑服务之间调用关系,还需考虑一些环境问题(如服务节点之间的资源竞争问题)尽可能综合更多的信息,才能更好地解决根因定位问题。在真实场景中,一个根因点可以从三个不同的维度进行分析:链上:将异常点在所处调用链上进行分析,推荐候选根因链间:处
10、在不同调用链上的候选根因成为最终根因的可能性是不同的全局拓扑:考虑全局异常传播拓扑,将候选根因进行逻辑汇聚,推荐最终根因在候选根因集合中,考虑全局拓扑、链间因素和链上因素,最终推荐接口级根因结合全局拓扑进行分析2023 深圳站三个分析维度链上链间全局拓扑2023 深圳站全局拓扑分析方法:基于状态压缩设计反向可达性表 注意到,在进行预处理时,首先会遍历该接口一定时间窗口内的正常调用链,此时可以考虑综合这些正常调用链,构建一张节点为各个服务的全局拓扑。不需要维护整张图,只需要关注节点之间的逻辑上下游关系。考虑对每个节点维护一张表,存储这个节点到其他节点的反向可达性。微服务众多,维护全局拓扑代价大,
11、能否优化?若A节点在B节点的逻辑上游且B反向可达A,则认为B处发生的异常由A处的异常传播导致。根因在图上两个节点的最近公共祖先(LCA)。进一步地,对于每个节点反向可达性表的维护,可采用状态压缩的思想,将节点是否反向可达的信息压缩成二进制串。用Bitmap等数据结构维护,能进一步减少时空开销(降低到64分之1)2023 深圳站候选根因排序:综合链上、链间、拓扑三个维度链上得分的确定:考虑链上span-event的结束时间戳,有理由认为结束时间越早的异常越可能是根因考虑异常偏离正常情况的程度,有理由认为偏离正常值越远的异常越可能是根因考虑异常类型的不同,有理由认为不用类型的异常成为根因的可能性是
12、不一样的链间得分的确定:认为耗时越大的调用链越需要被关注,得分越高对于链间耗时得分,更关注是否有离群点,对于耗时差别不大的一系列调用链,则耗时得分影响占比应较小;若有显著的耗时差异,则耗时得分影响占比应较大拓扑得分的确定:认为依次分析每条异常调用链得到的根因是候选根因,根据全局拓扑对这些候选根因进行处理:方式一(较严格):剔除存在逻辑上游的性能候选根因,最终得到的无上游候选根因即为最终推荐根因方式二(较宽松):对每个服务节点,根据全局拓扑计算处于其逻辑下游的候选根因个数,将这个数量记为该节点的传播分数,传播分数越大,越认为该服务节点为根因节点最终根据对以上三类得分的评价情况,综合上述考虑进行合
13、成,最终得到最终根因得分公式:2023 深圳站基于反馈数据的排序学习模型改善推荐根因准确性排序学习:排序学习是一个有监督的机器学习过程,对每一个给定的查询文档对,抽取特征,通过日志挖掘或者人工标注的方法获得真实数据标注。然后通过排序模型(LambdaMart),使得输入能够和实际的数据相似。排序场景文档检索性能恶化根因定位查询用户输入语句待分析服务信息信息文档集合调用链偏离正常模式差异点排序结果文档排序性能恶化根因排序标签获取人工标注/日志挖掘/点击率/停留时间人工反馈(打分/正负判断/点击率/顺序)待分析服务信息调用链偏离正常模式差异点差异点包含服务类型、事件关系、各类参数、时间、关键词、原
14、始文本等及它们发生的顺序专家规则/利用失败表象-差异相似性排序/排序学习模型差异点排序根因推荐主动/被动式收集反馈数据驱动的排序学习模型推荐根因类比性能恶化根因定位场景2023 深圳站有益效果2023 深圳站有益效果本方案可自动化比较异常点,并给出接口粒度的根因,如服务增减、事件关系增减、参数异变、耗时过长等本方案不/弱依赖人工经验:服务的调用链正常模式提取是数据驱动,不需要或只需要少量业务知识本方案无需人工标注数据,且能推荐未知根因本方案能汇聚多条调用链数据进行综合分析,结合全局拓扑情况给出有效推荐本方案综合链上因素、链间因素和拓扑因素进行综合分析,考虑因素全面,能对多根因问题和调用链异常相
15、互影响问题作出较好识别在华为业务场景中,采用本方案效果有较大提升2023 深圳站效率提升5040855050100分析准确率单次分析耗时分析效率提升改进前改进后效率提升:1、服务性能恶化根因分析准确率由50%提升至85%2、服务单次分析平均耗时由40分钟降低至5分钟,提升分析效率87.5%2023 深圳站真实案例2023 深圳站真实案例2023 深圳站总结2023 深圳站总结本方案提出了一种先在异常调用链内部分析候选根因,再在全局拓扑环境下对候选根因进行汇聚的二级分析方法,主要步骤如下:正常调用链模板库的建立全局拓扑(节点反向可达性表)的建立调用链上的异常检测和候选根因分析结合全局拓扑,多维打
16、分,对候选根因进行汇聚并推荐最终根因对于全局拓扑的构建,本方案创新性地提出了利用节点反向可达性表来维护的思想,进一步提出了结合状态压缩的二进制存储思路,提升了算法的时空效率。对于最终根因的推荐,本方案提出计算三项得分的多维评价方法,综合考虑真实环境中的各种可能因素,更好地推荐根因。感谢聆听CSDN全球最大的中文开发者社区平台CSDN全球最大的中文开发者社区平台CSDN创立于1999年全球编程类网站排名第7(来源:Similarweb 2023.04)注册用户超过4300万,覆盖90%的中文开发者新媒体矩阵粉丝数量超过3100万超过1000家企业客户和合作伙伴目前公司员工近800名,分布在北京、长沙、上海、深圳、杭州、成都等城市,并在美国硅谷常设办事处旗下品牌旗下品牌专业中文IT技术社区:CSDN.NET多媒体专业出版:新程序员开发者专属移动APP:CSDN APP代码托管协作平台:GitCode代码工具协同平台:InsCodeIT人力资源服务:科锐福克斯丨八爪网络高校IT技术学习成长平台:高校俱乐部