CN115114064A - 一种微服务故障分析方法、***、设备及存储介质 - Google Patents

一种微服务故障分析方法、***、设备及存储介质 Download PDF

Info

Publication number
CN115114064A
CN115114064A CN202210725381.4A CN202210725381A CN115114064A CN 115114064 A CN115114064 A CN 115114064A CN 202210725381 A CN202210725381 A CN 202210725381A CN 115114064 A CN115114064 A CN 115114064A
Authority
CN
China
Prior art keywords
service
micro
microservice
data
calling
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210725381.4A
Other languages
English (en)
Inventor
林秀
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Suzhou Inspur Intelligent Technology Co Ltd
Original Assignee
Suzhou Inspur Intelligent Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Suzhou Inspur Intelligent Technology Co Ltd filed Critical Suzhou Inspur Intelligent Technology Co Ltd
Priority to CN202210725381.4A priority Critical patent/CN115114064A/zh
Publication of CN115114064A publication Critical patent/CN115114064A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079Root cause analysis, i.e. error or fault diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明提出一种微服务故障分析方法,包括:实时收集微服务中不同层级的运行状态数据,并将运行状态数据作为微服务的日志数据;响应于微服务出现故障,创建新的微服务并基于所述日志数据在所述新的微服务中复现微服务运行过程;基于所述日志数据对所述新的微服务运行过程产生的运行状态数据进行对比,并根据对比结果确定对应的故障点。通过本发明提出的一种微服务故障分析方法,收集微服务运行过程中关键位置的运行数据或运行状态数据,在微服务出现故障时通过收集到的运行数据或运行状态数据在创建新的微服务并通过收集到的运行数据复现对应的微服务的运行过程同时收集复现的微服务的运行状态数据以此来分析出现故障的原因。

Description

一种微服务故障分析方法、***、设备及存储介质
技术领域
本发明属于计算机领域,具体涉及一种微服务故障分析方法、***、设备及存储介质。
背景技术
工业界广泛采用微服务架构,一个大型的企业级微服务由容器编排***管理着成百上千的微服务,采用微服务调用的方式响应API请求,微服务数量的庞大和错综复杂的调用链路,包括同步和异步调用,使得微服务发生故障时,花费大量的复现和排查时间,以确定排查范围。
现有的实现中,基于日志分析与可视化的微服务***故障定位策略进行故障诊断,BLA(Basic Log Analysis,基于日志分析)和VLA(Visual Log Analysis,可视化日志分析)是结构化和可视化的,以统计图表进行故障定位,有多种基于日志分析与可视化的微服务***故障定位策略,构建了相应的分析工具,并在所重现的故障案例基础上进行了实践对比和分析。故障发生起始点到有异常表现时,时间跨度较大,调用链路数量庞大和复杂。零代码侵入时,故障复现和复测难度大,耗时长。
因此,亟需一种有效的方案来解决上述问题。
发明内容
为解决以上问题,本发明提出一种微服务故障分析方法,包括:
实时收集微服务中不同层级的运行状态数据,并将运行状态数据作为微服务的日志数据;
响应于微服务出现故障,创建新的微服务并基于所述日志数据在所述新的微服务中复现微服务运行过程;
基于所述日志数据对所述新的微服务运行过程产生的运行状态数据进行对比,并根据对比结果确定对应的故障点。
在本发明的一些实施方式中,方法还包括:
对所述日志数据中进行分类,将相同操作的运行状态数据进行对比,并根据比对结果确定故障点。
在本发明的一些实施方式中,实时收集微服务中不同层级的运行状态数据,并将运行状态数据作为微服务的日志数据包括:
基于微服务的运行过程确定多个关键点,并记录所述微服务在所述关键点上对应的状态数据,并将状态数据作为所述微服务的日志数据。
在本发明的一些实施方式中,方法还包括:
根据所述日志数据确定微服务的调用链路,并按预设规则判断所述调用链路是否为不完整调用链路和/或异常调用链路。
在本发明的一些实施方式中,方法还包括:
根据所述关键点分析微服务内部API服务调用过程的上下文信息,确定故障发生的可疑位置。
在本发明的一些实施方式中,方法还包括
根据微服务的版本基于对应的微服务的调用链路返回值分析所述版本下微服务内部函数并确定对应的不稳定函数。
在本发明的一些实施方式中,方法还包括:
基于所述日志数据分析出对应链路调用关系并基于所述日志数据计算所述链路调用关系使得所述微服务出现异常的概率;
基于所述微服务出现异常的概率对运行中的微服务的调用链路出现异常的可能性进行预测并给出预测概率;
响应于所述预测概率达到预定值,保存对应的链路调用请求并监控所述调用请求的微服务对所述请求的反馈状态;
响应于所述反馈状态失败,则将保存的所述链路请求发送到提供相同服务的微服务上。
本发明的另一方面还提出一种微服务故障分析***,包括:
日志收集模块,所述日志收集模块配置用于实时收集微服务中不同层级的运行状态数据,并将运行状态数据作为微服务的日志数据;
故障复现模块,所述故障复现模块配置用于响应于微服务出现故障,创建新的微服务并基于所述日志数据在所述新的微服务中复现微服务运行过程;
故障分析模块,所述故障分析模块配置用于基于所述日志数据对所述新的微服务运行过程产生的运行状态数据进行对比,并根据对比结果确定对应的故障点。
本发明的又一方面还提出一种计算机设备,包括:
至少一个处理器;以及
存储器,所述存储器存储有可在所述处理器上运行的计算机指令,所述指令由所述处理器执行时实现上述实施方式中任意一项所述方法的步骤。
本发明的再一方面还提出一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行时实现上述实施方式中任意一项所述方法的步骤。
通过本发明提出的一种微服务故障分析方法,收集微服务运行过程中关键位置的运行数据或运行状态数据,在微服务出现故障时通过收集到的运行数据或运行状态数据在创建新的微服务并通过收集到的运行数据复现对应的微服务的运行过程同时收集复现的微服务的运行状态数据以此来分析出现故障的原因。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种微服务故障分析方法的方法流程图;
图2为本发明实施例提供的一种微服务故障分析***的***结构示意图。
图3为本发明实施例提供的一种计算机设备的结构示意图。
图4为本发明实施例提供的一种计算机可读存储介质的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白,以下结合具体实施例,并参照附图,对本发明实施例进一步详细说明。
本发明应用于故障分析领域,具体是指在微服务项目上线运行后的出现故障后的分析,不同于在项目开发阶段的debug过程,在传统的实现方式中,只能通过收集微服务的运行日志并基于收集的日志人为分析微服务的故障的原因,但由于对于大型的企业级的微服务来说,一个***内的微服务可能成百上千个,按照传统的分析方式是对故障的微服务日志进行分析只能根据日志中记录的内容推断出现问题的原因。例如现有的实施方案中,通过收集微服务运行中各个函数之间的数据传递过程,即每个函数的入参以及返回值,当微服务出现问题时通过收集的数据以函数调用的方式进行验证以确定对应的微服务的运行中哪些函数节点出现问题,来实现对微服务的故障分析。该实现方式需要运维人员将对应的微服务的函数代码按照收集的数据所形成的调用链路摘出对应的函数代码,然后形成新的测试项目(将多个函数形成一个执行程序),不同的调用链路形成不同的测试项目,最后以debug的方式向形成的测试项目传递收集的数据模拟相应的函数的“调用链路”。这种方式虽然可以有效的识别出收集的数据中在哪些函数节点出现错误(假设收集的数据中存在错误,但代码逻辑正常,则可以通过该方式查出微服务运行时收集的哪些函数的返回值出错),但是无法体现微服务中运行的代码因何而错(假设代码逻辑正常,一般上线的项目代码逻辑很少出现异常)。因此难以及时有效地确认出现问题的原因(即代码逻辑正常,但微服务却故障频出),并且在通过传统的日志分析时,对分析人员的要求也很高,在一些情况下可能需要研发人员对出现故障的微服务的日志进行分析。占用研发人员的开发时间,如前所述,对于不同的函数调用链路则形成不同的代码调用流程的测试项目,函数的排列组合、庞大的微服务个数都将造成运维成本的增加。
如图1所示,为解决上述问题本发明提出一种微服务故障分析方法,包括:
步骤S1、实时收集微服务中不同层级的运行状态数据,并将运行状态数据作为微服务的日志数据;
步骤S2、响应于微服务出现故障,创建新的微服务并基于所述日志数据在所述新的微服务中复现微服务运行过程;
步骤S3、基于所述日志数据对所述新的微服务运行过程产生的运行状态数据进行对比,并根据对比结果确定对应的故障点。
在本发明的实施例中,在步骤S1中实时收集微服务中不同层级的运行状态数据是指在不同的维度上收集微服务运行数据,包括微服务接收到的请求以及根据请求给出的结果,以及请求到达微服务后,微服务对该请求处理的整个过程中因该请求而产生的一些内部数据,所谓内部数据,包括微服务内部函数之间调用时每个函数的入参和返回值,还包括函数内部执行流程关键节点的中间数据。例如以用户认证微服务为例,当前端传来认证请求后,请求中包含账号和密码等数据内容,传递来的账号和密码将被作为日志数据记录,用户认证微服务则根据该账号密码查询数据库,向数据库发送的查询指令也会被记录到日志数据中,进一步数据库返回的数据内容也会被记录到日志数据中,用户认证微服务在收到对应的数据库返回的数据后和前段发送的账号密码经过计算后进行验证,验证的结果也将作为该微服务的不同层级的微运行状态数据作为日志数据。进一步,本发明实施例中的不同层级的运行状态数据可以根据微服务的业务不同进行区别设定,上述举例中是以用户认证过程中:前端发送的账户密码、用户认证微服务接收账户密码后发送给数据库的查询指令、从数据库返回的查询数据、用户认证微服务根据数据库返回的查询数据和账户密码计算后的校验结果等数据内容作为该用户认证微服务的运行状态数据,对于不同业务类型的微服务的不同层级的运行状态数据可根据不同的微服务进行灵活选择。
在本发明的一些实施例中,本发明中的日志数据并不是单单指一个微服务或一个容器内的日志数据,当涉及多个微服务的协同配合完成对应的业务时,日志数据将涉及多个微服务,即日志数据是以微服务调用链路的形式出现。
在步骤S2中,当某一个微服务出现故障时,创建一个与该微服务功能完全相同的一个空白的微服务,并将在故障微服务上收集的含有不同层级的运行数据按照日志记载的顺序模拟微服务调用的方式在新创建的微服务上运行以复现该微服务出现故障前的运行环境及运行状态。
需要说明的时,在本发明的实施例中,微服务都是以容器的方式进行部署,便于创建以及移植对应的微服务,因此可以创建新的容器再以复现的方式加载故障微服务的日志数据模拟故障前的微服务的运行过程。
在步骤S3中对过新创建的微服务的运行状态进行监控,同样收集新创建的微服务的运行状态数据,然后与已故障的微服务的日志数据中的运行状态数据进行对比找出异常点。
在本发明的一些实施例中,创建的微服务的个数可能不止一个,即根据不同故障的微服务所述的调用链,将涉及到的其他微服务也一同创建。
在本发明的一些实施方式中,方法还包括:
对所述日志数据中进行分类,将相同操作的运行状态数据进行对比,并根据比对结果确定故障点。
在本实施例中,如前所述,调用链路是指微服务之间的请求链路或访问链路,在一些情况下有些业务需要多个微服务配合完成,并且在该业务下多个微服务的访问流程固定或者传递的数据相同,例如都是指令型请求。因此,可以通过对日志数据的调用链进行分类,将相同的调用链路(是满足一个业务的链路,例如,微服务1调用微服务2,微服务2再访问微服务3,即由微服务1→微服务2→微服务3的这一部分链路)或者是在业务上属于相同业务进行相互对比,即由多个“微服务1→微服务2→微服务3”的调用链路上的运行状态数据进行对比,如果分类后的某条调用链路在上述链路中在微服务3处记录的数据与其他分类后的调用链路在微服务3除记录的数据不同,则说明微服务3处理该分类后的调用链路时的输出数据异常,这异常可能是直接导致微服务故障的触发因素,也可能是该输出数据在微服务后续的链路中因其他微服务收到该输出数据后导致其他微服务报错进而触发微服务故障。因此可通上述过程基于日志数据中的调用链路的对比找到故障点。
在本发明的一些实施方式中,实时收集微服务中不同层级的运行状态数据,并将运行状态数据作为微服务的日志数据包括:
基于微服务的运行过程确定多个关键点,并记录所述微服务在所述关键点上对应的状态数据,并将状态数据作为所述微服务的日志数据。
在本实施例中,微服务中的运行状态数据收集可进一步细化,为实现对微服务内部运行数据的,本发明在微服务内部设置多个关键点包括:微服务的入口,即微服务接收的请求以及请求内容;微服务内部运行过程中影响微服务正常运行的关键点,例如对请求的鉴权服务等;微服务接收的请求内容中传入到微服务的数据;微服务核心功能模块内的多个关键操作对应的数据,以及核心功能模块的返回值或输出值;微服务反馈给其他调用者(微服务)的返回值。
在本发明的一些实施例中,上述关键点只是按照微服务的运行过程设定的5类关键点,并不是只有5个数据,每一个关键点根据微服务的不同可能包含不同的数据,例如核心功能对应的关键点,在一些实施例中,是在代码层面将所有的核心功能涉及的函数的入口参数和返回值都进行收集。
在本发明的一些实施例中,对核心功能函数内部流程中的多个重要的运算数据或运算结果进行收集记录。以方便后续通过记录的多个重要运算数据分析核心功能函数的运行是否正常。
在本发明的一些实施方式中,方法还包括:
根据所述日志数据确定微服务的调用链路,并按预设规则判断所述调用链路是否为不完整调用链路和/或异常调用链路。
在本实施例中,从多个微服务日志数据中微服务访问其他微服务的访问记录确定对应微服务的调用链路,并将作为被访问的微服务的返回值或反馈信息作为调用链路完整性或异常的判断依据。
特别地,被访问的微服务的返回值或反馈信息并不一定会反馈给调用的微服务,有可能是被访问的微服务访问另外一个微服务,由另外一个微服务反馈给调用者(发起访问的微服务),即微服务1调用微服务2,微服务2不向微服务1反馈,而是调用微服务3,由微服务3向微服务1反馈对应的数据。预设规则则包括微服务的调用关系,并且即便是相同的几个微服务,在不同的业务请求下调用链路也不相同,因此需要按照预设的规则梳理调用链路关系。以准确的确定不完整调用链路或异常调用链路。以防止出现因调用链路复杂且不同请求的反馈值错发到其他微服务上的情况。
在本发明的一些实施方式中,方法还包括:
根据所述关键点分析微服务内部API服务调用过程的上下文信息,确定故障发生的可疑位置。
在本实施例中,微服务内部API是指微服务内部模块的结构接口或者是程序或函数接口。上下文信息是指API的输入数据和输出数据等信息。上述多个分类对应的多个关键点最小粒度为微服务内部各个模块的API接口数据,在一些情况下,还可对各个模块的API内部一个函数或多个函数内的入参或关键参数的数据进行收集。因此最低情况下可根据上述关键点数据确定是微服务内对应的模块是否出错。例如,某微服务内部可分为3个模块,三个模块提供三个调用接口(API),即可对微服务外部提供,也可对微服务内部使用,当微服务出现故障时,可通过三个接口的输入数据或输出数据即上下文确认是哪个模块出现问题,即可疑位置。
在发明的一些实施例中,如果收集的运行数据中包括某个关键函数的内部的逻辑流程的中的关键数据,则在微服务复现时,还包括将复现的微服务运行时对应的关键数据与收集关键数据进行过对比,例如某些推理微服务运行过程中每一层神经网络的输出的特征值作为关键数据被收集。
在本发明的一些实施方式中,方法还包括
根据微服务的版本基于对应的微服务的调用链路返回值分析所述版本下微服务内部函数并确定对应的不稳定函数。
在本实施例中,当收集的微服务的运行状态数据足够细化,即可以囊括微服务内运行的所有程序在源代层面的所有函数的输入输出数据(即函数的入参和返回值)或函数内部关键节点的某些关键的变量的值,则可以通过复现过程中以验证的方式确定微服务当前版本下哪些函数会随着运行时间的累计或者运行次数的任务量的出现不稳定的情况,即缓存数据越界、参数边界溢出等情况。
在本发明的一些实施方式中,需要说明的是在以收集的运行时的数据复现的方式分为两种,一种是按照日志数据中的时间间隔,在新的微服务内按照日志数据中记载的调用方式复现日志数据中的调用链路以及对应的数据,完整体现微服务的数据访问压力,即1秒内有100个请求,则模拟100个请求发送到对应的微服务。
此外,另一种则是不按照日志数据中记录的时间间隔而是一个调用链路或一个请求完成才进行下一个调用链路或请求。以此来确认哪些函数在高并发下存函数调用栈溢出或缓存数据越界等不稳定的情况,即找出对应的不稳定函数。
在本发明的一些实施例中,上述两种微服务复现方式可以同时进行并按照日志数据中对应的调用链路所产生的数据进行相互对比,以此分析出微服务之间以及微服务内部在任务运行压力等生成环境下某些函数出现异常的可能性。即非代码逻辑问题而是由于开发时对函数处理能力的考虑不足包括:数据过多、空间不足、函数调用栈异常、强制转换时变量异常等因实际运行时由用户请求的任务中数据的千奇百怪而造成的未知因素的影响。
即通过上述两种复现方式可以找出在运行时间的累积、运行次数累积下和微服务访问请求高压力下的不稳定函数,以及验证对应函数的结果的正确性。
在本发明的一些实施方式中,方法还包括:
基于所述日志数据分析出对应链路调用关系并基于所述日志数据计算所述链路调用关系使得所述微服务出现异常的概率;
基于所述微服务出现异常的概率对运行中的微服务的调用链路出现异常的可能性进行预测并给出预测概率;
响应于所述预测概率达到预定值,保存对应的链路调用请求并监控所述调用请求的微服务对所述请求的反馈状态;
响应于所述反馈状态失败,则将保存的所述链路请求发送到提供相同服务的微服务上。
在本实施例中,在通过上述以新微服务通过收集到的运行状态数据复现的情况下得出微服务异常的原因之后,则根据确定的微服务故障次数(基于时间间隔压力的情况,即基于运行时间的累积或者运行次数的增加),确定访问相应的微服务的出现异常的概率,并将通过异常的概率对正在运行的微服务的访问链路进行预测。
进一步,当某微服务运行压力达到一定程度(运行时间的累积或者运行次数的增加),对该微服务的预测出现故障的概率达到对应的警戒值时,则可将正在运行的其他微服务发送到该微服务的请求发送待该微服务的同时暂时保存,并监控该微服务的状态,如果出现异常则将暂时保存的请求发送到其他和该微服务功能相同的微服务上。由其他微服务提供该改微服务的功能。保证业务***的正常运行。
实施例:
使用日志管理服务记录的微服务***的所有微服务的操作历史记录,进行快速准确的故障复现。日志管理服务记录了微服务***的所有历史操作,详细记录了每个微服务的操作信息,包括微服务的API,微服务的输入参数,微服务的返回值,操作用户等信息,可以根据这些信息按照操作到来的时间顺序进行快速的故障复现。故障发生后,在复现环境下,复现服务会根据日志服务记录的操作日志,根据操作者和时间顺序逐条执行这些操作,恢复操作内容。
在本方案微服务***中,业务服务一为推理服务,业务服务二为用户管理服务,业务服务三为镜像分发服务,操作用户1登录***后,使用镜像分发服务上传业务镜像,日志服务保存了n条记录,如表1所示:
Figure BDA0003713035960000111
表1
推理服务使用镜像创建推理服务,日志服务保存n条操作记录,如表2所示:
Figure BDA0003713035960000112
表2
推理服务使用镜像创建第n+1个推理服务时,推理服务异常退出,日志服务未记录下此次操作的完整过程,如表3所示,第n+1个推理服务操作只记录了开始调用,未记录下返回结果,故障已经复现,推理服务推出,出现不完整链路。
Figure BDA0003713035960000121
表3
进一步进行实时轨迹分析服务:根据日志服务的记录,查找***微服务的不完整调用链路和异常调用链路,找出故障发生的可疑位置,确定发生故障的微服务及API,再通过日志管理服务记录的关键点,分析服务内部执行API服务调用过程的上下文信息,确定故障发生的可疑起始位置。服务内部的关键点是指标识服务内部的重要变量,函数返回值,决定服务调用分支的变量,影响其他微服务的标识等。关键点是执行API服务调用过程中重要的阶段性的状态信息,正常API调用过程中的关键点信息与异常的信息进行比较,关键点不同处,可以确定服务内部具体故障起始位置。
故障发生时创建推理服务具有不完整的调用链路,只有服务调用的起始,没有返回结果,且前面多次微服务调用的状态码都正常,由此可疑判断故障发生在n+1次推理服务API调用过程中,确定故障发生在第n+1次服务调用过程中,还需要根据服务内部关键点状态值确定服务内故障发生的具***置信息。服务内部共有5出关键点记录日志:
第一个关键点:服务调用入口起始位置,记录服务入口时,环境变量值,传入参数值,
第二个关键点:服务内调用其他服务即调用鉴权服务返回值是否正确,
第三个关键点:传入参数检查是否正确,包括传入参数和业务资源总量是否有效,
第四个关键点:创建推理服务修改操作过程及返回信息是否正确,
第五个关键点:服务返回值是否正确。前面第n次调用都为正常调用过程,日志信息为正确调用日志信息,比对n+1次部分日志信息,
第一个关键点服务调用入口起始位置记录第n次和第n+1次时相似的,没有异常,第二个关键点调用其他服务返回值的状态码时正常的,第三个关键点参数和业务资源有效性校验,第n次函数执行服务返回校验正常,第n+1次校验函数未收到返回值,初步判断第n+1次服务调用内的第三个关键点就是故障发生的范围。第n次和第n+1次传入参数和业务资源校验代码逻辑相同,不同的是执行次数,可以使用静态分析服务分析第三个关键点返回值故障发生的原因。。
进一步根据服务的版本,静态分析代码调用关系,及服务调用链路返回值,及随时间和执行次数增加返回值不稳定的函数,缓存数据越界,参数边界值判断等方法。使用静态分析服务分析出微服务内部函数输入参数增加导致返回值数据膨胀的函数,因为服务内部需要判断n+1次数据的排列,按照最优算法选出占用资源总量最小的排列方法,根据时间和执行次数的增长,排列输出的数据就会急剧膨胀,导致故障发生,服务退出。静态分析服务可以提供查找代码中不确定因素的方式给出故障发生的可能原因。
进一步根据历史轨迹日志分析出可能的链路调用关系。结合预测服务给出的可能调用链扩展实时轨迹分析服务分析出的调用链路,扩展出可以的故障原因。
通过本发明提出的一种微服务故障分析方法,收集微服务运行过程中关键位置的运行数据或运行状态数据,在微服务出现故障时通过收集到的运行数据或运行状态数据在创建新的微服务并通过收集到的运行数据复现对应的微服务的运行过程同时收集复现的微服务的运行状态数据以此来分析出现故障的原因。解决复杂庞大调用链路的故障复现难度大问题,降低复现时间,故障复现后,在数量庞大和复杂的调用链路中准确找出有问题的调用链路的方法。
相比于现有技术中以微服务内函数的调用关系形成的调用链的方式进行故障分析。本发明可由相应的运维人员创建一个或多个容器并在容器中创建对应的微服务,进一步通过通用的测试工具向创建的微服务发送收集到的运行数据并获取对应的返回结果与收集到运行数据作对比进行故障分析,或者通过多组复现微服务(模拟正常的请求压力和不模拟对应的请求压力)的运行结果相互对比得到故障原因。无需再在代码层面进行操作,即可实现多角度的故障分析服务。在项目代码开发完成后(项目代码中嵌入有收集数据的函数接口)便可实现后续故障分析功能,一次开发终身收益。解决现有的微服务故障分析技术中复测难度大,耗时长,对分析人员要求高的问题。同时通过复现的方式更容易向运维人员或开发人员显示出在庞大任务量或运行时长累计情况下微服务架构上的设计缺陷等层面的问题。
如图2所示,本发明的另一方面还提出一种微服务故障分析***,包括:
日志收集模块1,所述日志收集模块1配置用于实时收集微服务中不同层级的运行状态数据,并将运行状态数据作为微服务的日志数据;
故障复现模块2,所述故障复现模块2配置用于响应于微服务出现故障,创建新的微服务并基于所述日志数据在所述新的微服务中复现微服务运行过程;
故障分析模块3,所述故障分析模块3配置用于基于所述日志数据对所述新的微服务运行过程产生的运行状态数据进行对比,并根据对比结果确定对应的故障点。
如图3所示,本发明的又一方面还提出一种计算机设备,包括:
至少一个处理器21;以及
存储器22,所述存储器22存储有可在所述处理器21上运行的计算机指令23,所述指令23由所述处理器21执行时实现上述实施方式中任意一种方法的步骤。
如图4所示,本发明的再一方面还提出一种计算机可读存储介质401,所述计算机可读存储介质401存储有计算机程序402,所述计算机程序被处理器执行时实现上述实施方式中任意一种方法的步骤。
以上是本发明公开的示例性实施例,但是应当注意,在不背离权利要求限定的本发明实施例公开的范围的前提下,可以进行多种改变和修改。根据这里描述的公开实施例的方法权利要求的功能、步骤和/或动作不需以任何特定顺序执行。此外,尽管本发明实施例公开的元素可以以个体形式描述或要求,但除非明确限制为单数,也可以理解为多个。
应当理解的是,在本文中使用的,除非上下文清楚地支持例外情况,单数形式“一个”旨在也包括复数形式。还应当理解的是,在本文中使用的“和/或”是指包括一个或者一个以上相关联地列出的项目的任意和所有可能组合。
上述本发明实施例公开实施例序号仅仅为了描述,不代表实施例的优劣。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
所属领域的普通技术人员应当理解:以上任何实施例的讨论仅为示例性的,并非旨在暗示本发明实施例公开的范围(包括权利要求)被限于这些例子;在本发明实施例的思路下,以上实施例或者不同实施例中的技术特征之间也可以进行组合,并存在如上所述的本发明实施例的不同方面的许多其它变化,为了简明它们没有在细节中提供。因此,凡在本发明实施例的精神和原则之内,所做的任何省略、修改、等同替换、改进等,均应包含在本发明实施例的保护范围之内。

Claims (10)

1.一种微服务故障分析方法,其特征在于,包括:
实时收集微服务中不同层级的运行状态数据,并将运行状态数据作为微服务的日志数据;
响应于微服务出现故障,创建新的微服务并基于所述日志数据在所述新的微服务中复现微服务运行过程;
基于所述日志数据对所述新的微服务运行过程产生的运行状态数据进行对比,并根据对比结果确定对应的故障点。
2.根据权利要求1所述的方法,其特征在于,还包括:
对所述日志数据中进行分类,将相同操作的运行状态数据进行对比,并根据比对结果确定故障点。
3.根据权利要求1所述的方法,其特征在于,所述实时收集微服务中不同层级的运行状态数据,并将运行状态数据作为微服务的日志数据包括:
基于微服务的运行过程确定多个关键点,并记录所述微服务在所述关键点上对应的状态数据,并将状态数据作为所述微服务的日志数据。
4.根据权利要求3所述的方法,其特征在于,还包括:
根据所述日志数据确定微服务的调用链路,并按预设规则判断所述调用链路是否为不完整调用链路和/或异常调用链路。
5.根据权利要求3所述的方法,其特征在于,还包括:
根据所述关键点分析微服务内部API服务调用过程的上下文信息,确定故障发生的可疑位置。
6.根据权利要求1所述的方法,其特征在于,还包括
根据微服务的版本基于对应的微服务的调用链路返回值分析所述版本下微服务内部函数并确定对应的不稳定函数。
7.根据权利要求1所述的方法,其特征在于,还包括:
基于所述日志数据分析出对应链路调用关系并基于所述日志数据计算所述链路调用关系使得所述微服务出现异常的概率;
基于所述微服务出现异常的概率对运行中的微服务的调用链路出现异常的可能性进行预测并给出预测概率;
响应于所述预测概率达到预定值,保存对应的链路调用请求并监控所述调用请求的微服务对所述请求的反馈状态;
响应于所述反馈状态失败,则将保存的所述链路请求发送到提供相同服务的微服务上。
8.一种微服务故障分析***,其特征在于,包括:
日志收集模块,所述日志收集模块配置用于实时收集微服务中不同层级的运行状态数据,并将运行状态数据作为微服务的日志数据;
故障复现模块,所述故障复现模块配置用于响应于微服务出现故障,创建新的微服务并基于所述日志数据在所述新的微服务中复现微服务运行过程;
故障分析模块,所述故障分析模块配置用于基于所述日志数据对所述新的微服务运行过程产生的运行状态数据进行对比,并根据对比结果确定对应的故障点。
9.一种计算机设备,其特征在于,包括:
至少一个处理器;以及
存储器,所述存储器存储有可在所述处理器上运行的计算机指令,所述指令由所述处理器执行时实现权利要求1-7任意一项所述方法的步骤。
10.一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1-7任意一项所述方法的步骤。
CN202210725381.4A 2022-06-24 2022-06-24 一种微服务故障分析方法、***、设备及存储介质 Pending CN115114064A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210725381.4A CN115114064A (zh) 2022-06-24 2022-06-24 一种微服务故障分析方法、***、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210725381.4A CN115114064A (zh) 2022-06-24 2022-06-24 一种微服务故障分析方法、***、设备及存储介质

Publications (1)

Publication Number Publication Date
CN115114064A true CN115114064A (zh) 2022-09-27

Family

ID=83328313

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210725381.4A Pending CN115114064A (zh) 2022-06-24 2022-06-24 一种微服务故障分析方法、***、设备及存储介质

Country Status (1)

Country Link
CN (1) CN115114064A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115941545A (zh) * 2022-10-14 2023-04-07 华能信息技术有限公司 一种基于微服务的日志管理方法及平台
CN115964214A (zh) * 2022-12-30 2023-04-14 广州市华势信息科技有限公司 一种多终端零代码智能软件开发平台

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113391943A (zh) * 2021-06-18 2021-09-14 广东工业大学 一种基于因果推断的微服务故障根因定位方法及装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113391943A (zh) * 2021-06-18 2021-09-14 广东工业大学 一种基于因果推断的微服务故障根因定位方法及装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115941545A (zh) * 2022-10-14 2023-04-07 华能信息技术有限公司 一种基于微服务的日志管理方法及平台
CN115941545B (zh) * 2022-10-14 2023-06-23 华能信息技术有限公司 一种基于微服务的日志管理方法及平台
CN115964214A (zh) * 2022-12-30 2023-04-14 广州市华势信息科技有限公司 一种多终端零代码智能软件开发平台
CN115964214B (zh) * 2022-12-30 2023-07-14 广州市华势信息科技有限公司 一种多终端零代码智能软件开发平台

Similar Documents

Publication Publication Date Title
CN111209131B (zh) 一种基于机器学习确定异构***的故障的方法和***
US10102113B2 (en) Software test automation systems and methods
CN110928772B (zh) 一种测试方法及装置
CN110309071B (zh) 测试代码的生成方法及模块、测试方法及***
Zhao et al. Identifying bad software changes via multimodal anomaly detection for online service systems
US20120101800A1 (en) Model checking for distributed application validation
CN115114064A (zh) 一种微服务故障分析方法、***、设备及存储介质
CN113946499A (zh) 一种微服务链路跟踪及性能分析方法、***、设备及应用
CN113238924B (zh) 分布式图数据库***中的混沌工程实现方法和***
Dhanalaxmi et al. A review on software fault detection and prevention mechanism in software development activities
Liu et al. Incident-aware duplicate ticket aggregation for cloud systems
Ganatra et al. Detection is better than cure: A cloud incidents perspective
Yan et al. Aegis: Attribution of control plane change impact across layers and components for cloud systems
Valueian et al. Constructing automated test oracle for low observable software
CN112988444B (zh) 用于服务器集群故障诊断的处理方法、处理装置、及处理设备、用于服务器故障诊断的方法及计算机可读存储介质
CN115658470A (zh) 面向分布式***的失效恢复机制自动化测试方法及装置
Verma et al. Review of software fault-tolerance methods for reliability enhancement of real-time software systems
CN111813872B (zh) 一种故障排查模型的生成方法、装置、设备
Zhao et al. How to Manage Change-Induced Incidents? Lessons from the Study of Incident Life Cycle
Bhatia et al. Efficient failure diagnosis of OpenStack using Tempest
WO2020194000A1 (en) Method of detecting and removing defects
Chen et al. Proverr: System level statistical fault diagnosis using dependency model
Soomro et al. Fault localization models in debugging
CN117573530A (zh) 基于Jepsen测试的DApp链下异常状态检测方法及***
CN117992340A (zh) 数据库集群模糊测试方法、***、计算机设备和存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination