CN116107789A - 一种监测、分析应用故障原因的方法及存储介质 - Google Patents

一种监测、分析应用故障原因的方法及存储介质 Download PDF

Info

Publication number
CN116107789A
CN116107789A CN202310133621.6A CN202310133621A CN116107789A CN 116107789 A CN116107789 A CN 116107789A CN 202310133621 A CN202310133621 A CN 202310133621A CN 116107789 A CN116107789 A CN 116107789A
Authority
CN
China
Prior art keywords
abnormal
exception
request
application
response
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
CN202310133621.6A
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.)
Beijing Keynote Network Inc
Original Assignee
Beijing Keynote Network Inc
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 Beijing Keynote Network Inc filed Critical Beijing Keynote Network Inc
Priority to CN202310133621.6A priority Critical patent/CN116107789A/zh
Publication of CN116107789A publication Critical patent/CN116107789A/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/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/0706Error 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 the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0715Error 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 the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking

Landscapes

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

Abstract

本公开涉及一种监测、分析应用故障原因的方法及存储介质,该监测应用的方法包括:在应用接收到请求后,获取执行异常数据;在请求的响应开始时,获取事务错误数据;将执行异常数据和事务错误数据作为请求对应的故障监测数据发送给服务器。该分析应用故障原因的方法,包括:从应用探针获取的多个故障监测数据中,获取执行异常数据和/或事务错误数据包含的异常的信息;对同一异常名称的异常消息进行聚类,得到异常名称对应的异常消息条目;确定异常名称对应的异常消息条目的统计信息。通过本公开实现了故障监测数据采集和故障原因分析。

Description

一种监测、分析应用故障原因的方法及存储介质
相关申请的交叉引用
本申请是申请日为2021年9月22日、发明名称为“一种监测、分析应用故障原因的方法、设备及存储介质”的中国专利申请202111105762.4的分案申请,出于所有目的将其全文以引用方式并入本文。
技术领域
本公开涉及应用监测技术领域,尤其涉及一种监测、分析应用故障原因的方法及存储介质。
背景技术
应用在运行过程中,经常发生故障,导致用户体验下降,业务受损。相关技术中的处理办法根据异常日志文件分析异常原因。然而,日志文件并不能很好的分析应用故障原因。
发明内容
为了解决上述技术问题或者至少部分地解决上述技术问题,本公开提供了一种监测、分析应用故障原因的方法及存储介质。
第一方面,本公开提供了一种监测应用的方法,在应用接收到请求后,获取执行异常数据,包括:获取预设的业务方法执行中的异常的信息;在请求的响应开始时,获取事务错误数据,包括:获取预设的业务方法中入口方法未捕获的异常的信息;将执行异常数据和事务错误数据作为请求对应的故障监测数据发送给服务器。
在一些实施例中,获取预设的业务方法执行中的异常的信息之后,还包括:根据预设规则确定获取到的异常的信息是否属于事务错误数据;在获取到的异常的信息属于事务错误数据的情况下,将获取到的异常的信息归类到事务错误数据。
在一些实施例中,获取事务错误数据,还包括:获取业务错误的信息;和/或获取响应错误的信息。
在一些实施例中,获取预设的业务方法执行中的异常的信息,包括以下至少之一:通过异常处理程序的Hook来获取预设的业务方法执行中的异常的信息;在预设的业务方法执行中,监测日志组件是否在内存中记录有异常日志,在记录有异常日志的情况下,从内存中读取异常的信息。
在一些实施例中,还包括:对从内存中读取的异常和Hook获取的异常进行去重。
在一些实施例中,获取业务错误的信息,包括:从响应的预设位置获取业务错误的信息。
在一些实施例中,获取响应错误的信息,包括:获取响应状态码;判断响应状态码是否为预设响应状态码;在响应状态码为预设响应状态码的情况下,将响应状态码作为响应错误的信息。
在一些实施例中,上述方法还包括:根据异常分类规则确定异常的异常类型,其中,故障监测数据还包括异常类型。
第二方面,本公开提供了一种分析应用故障原因的方法,包括:从应用探针获取的多个故障监测数据中,获取执行异常数据和/或事务错误数据包含的异常的信息,异常的信息包括:异常名称、异常消息和堆栈跟踪;对同一异常名称的异常消息进行聚类,得到异常名称对应的异常消息条目;确定异常名称对应的异常消息条目的统计信息。
在一些实施例中,上述方法还包括:对异常消息条目对应的堆栈跟踪进行聚类,得到异常消息条目对应的方法调用分布;确定异常消息条目对应的方法调用分布的统计信息。
在一些实施例中,上述方法还包括:对异常消息条目对应的堆栈跟踪中根因部分的名称和消息进行聚类,得到异常消息条目对应的根因条目;确定异常消息条目对应的根因条目的统计信息。
在一些实施例中,上述方法还包括:对根因条目对应的根因堆栈跟踪进行聚类,得到根因条目对应的根因方法调用分布;确定根因条目对应的根因方法调用分布的统计信息。
第三方面,本公开提供了一种分析应用故障原因的方法,包括:向服务器发送第一请求,其中,第一请求携带有用户选择的异常名称;接收服务器响应于第一请求的第一响应,其中,第一响应携带有异常名称对应的异常消息条目及其统计信息,异常消息条目是对异常名称对应的异常消息进行聚类得到的;通过显示器显示异常消息条目及其统计信息。
在一些实施例中,上述方法还包括:向服务器发送第二请求,其中,第二请求携带有用户选择的异常消息条目;接收服务器发送的第二响应,其中,第二响应携带有方法调用分布及其统计信息,方法调用分布是对异常消息条目对应的堆栈跟踪进行聚类得到的;通过显示器显示方法调用分布及其统计信息。
在一些实施例中,上述方法还包括:向服务器发送第三请求,其中,第三请求携带有用户选择的异常消息条目;接收服务器发送的第三响应,其中,第三响应携带有根因条目及其统计信息,根因条目是对异常消息条目对应的堆栈跟踪中根因部分的名称和消息进行聚类得到的;通过显示器显示根因条目及其统计信息。
在一些实施例中,上述方法还包括:向服务器发送第四请求,其中,第四请求携带有用户选择的根因条目;接收服务器发送的第四响应,其中,第四响应携带有根因方法调用分布及其统计信息,根因方法调用分布是对根因条目对应的根因堆栈跟踪进行聚类得到的;通过显示器显示根因方法调用分布及其统计信息。
第四方面,本公开提供了一种服务器,包括:存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序;计算机程序被处理器执行时实现监控应用的方法的步骤。
第五方面,本公开提供了一种服务器,包括:存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序;计算机程序被处理器执行时实现分析应用故障原因的方法的步骤。
第六方面,本公开提供了一种电子设备,包括:存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序;计算机程序被处理器执行时实现分析应用故障原因的方法的步骤。
第七方面,本公开提供了一种计算机可读存储介质,计算机可读存储介质上存储有监测应用的程序,监测应用的程序被处理器执行时实现监测应用的方法的步骤。
第八方面,本公开提供了一种计算机可读存储介质,计算机可读存储介质上存储有分析应用故障原因的程序,分析应用故障原因的程序被处理器执行时实现分析应用故障原因的方法的步骤。
本公开实施例提供的上述技术方案与相关技术相比具有如下优点:本公开实施例提供的该方法,获取执行异常和事务错误,将执行异常数据和事务错误数据作为请求对应的故障监测数据发送给服务器,实现了对事务的全面监测。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本公开的实施例,并与说明书一起用于解释本公开的原理。
为了更清楚地说明本公开实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,对于本领域普通技术人员而言,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本公开实施例提供的一种应用系统一种实施方式的示意图;
图2为本公开实施例提供的应用系统另一种实施方式的示意图;
图3为本公开实施例提供的应用监测系统一种实施方式的示意图;
图4为本公开实施例提供的监测应用的方法一种实施方式的流程图;
图5为本公开实施例提供的分析应用故障原因的方法一种实施方式的流程图;
图6为本公开实施例提供的分析应用故障原因的方法另一种实施方式的流程图;
图7为本公开实施例提供的事务错误趋势分析的示意图;
图8为本公开实施例提供的事务错误分类统计的示意图;
图9为本公开实施例提供的执行异常趋势分析的示意图;
图10为本公开实施例提供的执行异常分类统计的示意图;
图11为本公开实施例提供的异常名称统计的示意图;
图12为本公开实施例提供的异常消息条目统计的示意图;
图13为本公开实施例提供的异常消息条目的方法调用分布的示意图;
图14为本公开实施例提供的异常消息条目的根因条目及根因方法调用分布的示意图;
图15为本公开实施例提供的计算机设备一种实施方式的硬件示意图。
具体实施方式
应当理解,此处所描述的具体实施例仅仅用以解释本公开,并不用于限定本公开。
在后续的描述中,使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本公开的说明,其本身没有特定的意义。因此,“模块”、“部件”或“单元”可以混合地使用。
本公开的一些示例涉及对应用监测的改进,本公开的另一些示例涉及对应用故障原因分析的改进。
在本公开中,术语“应用”包括实现与客户端交换数据的网络应用。术语“应用”也指微服务架构下的服务,此时,“应用”提供一项服务,例如电子商务中的“商品服务”、“订单服务”、“支付服务”等。
图1为本公开实施例提供的一种应用系统一种实施方式的示意图,如图1所示,应用系统100包括:电子设备110,电子设备110包括客户端111;服务器120,服务器120包括应用121和数据库122。
在本公开中,电子设备110可包括智能手机(例如,iPhone、Android手机等)、平板电脑(例如,iPad、Android平板等)、个人电脑(例如PC、MAC等)、智能音箱(例如,具有语音交互接口的音箱设备),客户端111可包括网页浏览器等。电子设备110通过网络与服务器120通信,以与服务器120交换数据。电子设备110可通过有线或无线方式接入网络,例如,4G、5G等移动蜂窝网络、Wi-Fi等无线网络,本公开实施例对此不做限定。
在本公开中,客户端111向应用121发送请求(request)131,应用121处理请求131向客户端111发送响应(response)132。以电子商务为例,应用121包括商品功能、订单功能、支付功能,客户端111可向服务器请求商品信息,并可选择商品提交订单,对提交的订单进行支付。应用121处理客户端111的商品请求,向客户端111提供商品信息,客户端111在电子设备110的显示屏上显示商品信息;应用121处理客户端111的订单请求,生成订单并向客户端111提供订单。
图2为本公开实施例提供的应用系统另一种实施方式的示意图,如图2所示,应用系统200采用微服务架构,应用系统200包括:电子设备210,电子设备210包括客户端211;微服务系统220,包括:服务器221a、221b、221c和221d等,服务器221a包括应用222a和数据库223a,服务器221b包括应用222a和数据库223a,服务器221b包括应用222b和数据库223b,服务器221c包括应用222c和数据库223c,服务器221d包括应用222d和数据库223d。
在本公开中,电子设备210可参见前述实施方式的说明,在此不做赘述。服务器221a、221b、221c和221d等的应用组成微服务系统,该微服务系统响应客户端211的请求(request),由一个或多个应用处理该请求,向客户端211发送响应(response)。该一个或多个应用构成调用链,示例性的,首先由应用222c处理请求,应用222c处理请求调用应用222a,应用222a调用应用222b。在该示例中,应用222c称为入口应用。
本公开实施例提供了一种应用监测系统,可以应用于金融、保险、互联网等行业IT运维自动化。图3为本公开实施例提供的应用监测系统一种实施方式的示意图,该应用监测系统可用于监测图1或图2所示的应用。如图3所示,应用监测系统300包括:应用探针310、服务器320和电子设备330。应用探针310被配置为监测应用,形成监测数据,并将监测数据发送给服务器320。服务器320被配置为接收并存储监测数据,以及向电子设备330提供信息,以供使用者331分析应用的状况。
在本公开中,使用者331包括但不限于应用的开发人员、应用运营中的业务人员。在本公开中,电子设备330可包括智能手机(例如,iPhone、Android手机等)、平板电脑(例如,iPad、Android平板等)、个人电脑(例如PC、MAC等)等,但不限于此。
在本公开中,涉及监测应用故障及分析应用故障,下面结合图1至图3,对本公开的监测应用的方法、分析应用故障原因的方法进行描述,但本公开并不限于此。
本公开实施例提供了一种监测应用的方法,该方法应用于应用探针310,对应用进行监测,形成故障监测数据并将故障监测数据发送给服务器320。
图4为本公开实施例提供的监测应用的方法一种实施方式的流程图,如图4所示,该方法包括步骤S402至步骤S406。
在本公开实施例中,故障监测数据分为执行异常数据和事务错误数据,执行异常数据与事务错误数据对应于对业务产生的不同影响的数据。在本公开实施例中,执行异常包括应用内部的异常,一般不影响用户使用,执行异常数据包括异常的信息;事务错误包括非正常响应,非正常响应影响用户使用,事务错数数据包括非正常响应的数据。
步骤S402,在应用接收到请求后,获取执行异常数据。
在本公开实施例中,执行异常包括应用内部发生的异常(Exception),这些异常多数情况下标识程序非正常运行,但不引起响应的错误。执行异常数据包括异常的信息。
在本公开实施例中,应用接收到调用求请求后,调用一个或多个业务方法以提供请求对应的响应。
以Java程序为例,业务方法执行过程中可能出现异常,如果出现异常,会生成一个异常类对象,该对象将被提交给Java运行时系统,这过程称为抛出(throw)异常。其中,在代码中没有找到相应的处理程序,在后台可自动创建一个对应异常类的实例对象并抛出;代码中可创建异常类型的对象或在方法体上抛出异常类型。
每个业务方法中可设置try块和catch块。将一个或者多个语句放入try时,则表示这些语句可能抛出异常,在出现异常时抛出异常。try块中检测到异常会将异常对象传递给catch块。catch块是try块所产生异常的接收者,catch捕获到异常进行处理。如果异常没有在调用者方法中得到处理,则继续被抛给这个方法的上层方法,直到异常被捕获处理。由此,实现将抛出来的异常进行捕获处理。
在本公开实施例中,获取执行异常数据包括:获取预设的业务方法执行中的异常的信息。在本公开实施例中,可对部分或全部业务方法进行监测,在实际应用中可根据需要进行配置。
在本公开实施例中,异常的信息包括:异常名称、异常消息(Exception Message)和堆栈追踪。示例性的,异常的信息示例性形式如下:
“异常名称”:异常消息
at“方法n”
at“方法1”
其中,堆栈跟踪为代码堆栈,记录了方法调用链。例如,异常发生在方法d
处,d方法是由方法c调用的,c方法是由b调用的,b方法是由方法a调用的,此时,堆栈追踪依次为d、c、b、a,异常的信息显示了异常发生在方法d,异常名称、异常消息,以及方法调用链(a->b->c->d)。
异常发生在方法d上,但该异常可能是由其调用的方法e导致的,方法e未处理其异常,将异常传递到其调用者方法d,此时,异常的信息中还包括causeby部分,示例性的如下:
“异常名称”:“异常消息”
at xxxx.d()
at xxxx.c()
at xxxx.b()
at xxxx.a()
causeby“名称”:“消息”
at xxxx.e()
at xxxx.d()
at xxxx.c()
at xxxx.b()
at xxxx.a()
在一些示例中,可包括多个causeby部分,例如方法e的异常是由起吊用的方法f产生的,此时异常的信息如下:
“异常名称”:“异常消息”
at xxxx.d()
at xxxx.c()
at xxxx.b()
at xxxx.a()
causeby“名称”:“消息”
at xxxx.e()
at xxxx.d()
at xxxx.c()
at xxxx.b()
at xxxx.a()
causeby“名称”:“消息”
at xxxx.f()
at xxxx.e()
at xxxx.d()
at xxxx.c()
at xxxx.b()
at xxxx.a()
一般地,最末端的causeby部分为异常的根本原因,称为根因,在上述示例中,即最终由方法f导致该异常发生。
在一些示例中,获取预设的业务方法执行中的异常的信息,包括:通过异常处理程序(例如Exception Handler)的Hook来获取预设的业务方法执行中的异常的信息。由此,实现对抛出的异常的监测和异常信息的获取。
在一另些示例中,在预设的业务方法执行中,监测日志组件是否在内存中记录有异常日志,在记录有异常日志的情况下,从内存中读取异常的信息。由此,可获取到未抛出的异常的信息。示例性的,可通过对日志组件进行Instrument操作来对日志组件进行监测。在一些示例中,可预先配置哪些异常被读取,例如,可配置读取异常和Error级别以上的异常消息。
在一又些示例中,获取预设的业务方法执行中的异常的信息,包括:通过异常处理程序(例如Exception Handler)的Hook来获取预设的业务方法执行中的异常的信息;以及,在预设的业务方法执行中,监测日志组件是否在内存中记录有异常日志,在记录有异常日志的情况下,从内存中读取异常的信息。
在一些示例中,抛出的异常通过Hook获取到,同时这些异常也可由日志组件处理,此时存在数据重复。因此,在一些示例中,对从内存中读取的异常和Hook获取的异常进行去重。由此,可降低数据传输量,并可降低服务器处理数据的复杂度。
在本公开实施例中,事务错数数据和执行异常数据可根据需要与其他数据关联作为请求对应的故障监测数据发送给服务器,本公开实施例对此不作限定。在一些示例中,在步骤S402中,还包括:获取请求信息。请求信息包括但不限于:请求的标识,和/或请求对应的事务请求的标识。在一些示例中,参考图1所示的应用系统,请求即为事务请求,通过请求的标识,可将监测数据与调用链关联。在另一些示例中,参考图2所示的应用系统,事务请求可对应于多个调用请求,通过事务请求的标识,可将监测数据与调用链关联,从而实现为微服务架构下多个应用的监测。
步骤S404,在请求的响应开始时,获取事务错误数据。
在本公开实施例中,事务错误包括用户在访问应用时出现的非正常响应,非正常响应影响用户使用,事务错误数据包括非正常响应的信息。在本公开实施例中,事务也可称为业务,非限制性的,事务可包括电子商务中的提交订单(对应的请求为下单请求)、支付(对应的请求为支付请求)。
如果异常没有在调用者方法中得到处理,则继续被抛给这个方法的上层方法,直到异常被捕获处理。由此,实现将抛出来的异常进行捕获处理。如果异常回到入口方法并且也未处理,则应用运行可能终止。上述步骤S404中,获取事务错误数据包括:获取预设的业务方法中入口方法未捕获(Uncaught)的异常的信息。示例性的,可通过异常处理程序(例如Exception Handler)的Hook来获取上述未捕获的异常的信息。
示例性的,一个请求涉及A、B、C和D四个业务方法,这四个业务方法顺序执行,A方法调用a1方法,a1方法调用a2方法,a2方法调用a3方法。可对A方法及其调用的a1、a2、a3方法进行监测,监测到a3方法出现异常,则获取该异常的信息。如果a3方法未处理该异常,则该异常传递到其调用者a2方法,a2处理该异常,则获取a2方法出现的异常。如果该异常传递到A还未处理,则此时出现未捕获的异常,此时应用运行终止,由此产生非正常响应,导致事务错误。
在一些示例中,一些执行异常不直接导致非正常响应,然而可能带来比较严重的用户体验降低,因此,可将这些执行异常归类到事务错误,在分类分析时,可实现对一般异常和引起用户体验降低的异常分开分析,从而可优先解决引起用户体验降低的异常。因此,上述步骤S402获取预设的业务方法执行中的异常的信息之后,还可根据预设规则确定获取到的异常的信息是否属于事务错误数据,在获取到的异常的信息属于事务错误数据的情况下,将获取到的异常的信息归类到事务错误数据。
应用可将业务错误的信息写入响应中,在一些示例中,获取事务错误数据,还包括:获取业务错误的信息。在一些示例中,获取业务错误的信息,包括:从响应的预设位置获取业务错误的信息。以HTTP响应为例,业务错误信息可设置在HTTP响应头或响应体中。实际应用中,业务错误的信息可使用错误码标识,或者可为错误消息,例如,在响应中写入“出库失败”,或者在响应中写入“BE-007”(指示发生编号为BE-007的业务错误,进一步的可根据编号与业务错误的对应关系确定该业务错误为“出库失败”)。在一些示例中,业务错误信息可设置在HTTP响应状态码(HTTP Response Status Code)中,使用自定义状态码标识业务错误。
在一些示例中,获取事务错误数据还包括:获取响应错误的信息。以HTTP响应为例,获取响应状态码;判断响应状态码是否为预设响应状态码;在响应状态码为预设响应状态码的情况下,将响应状态码作为响应错误的信息。HTTP响应状态码由三个十进制数字组成,第一个十进制数字定义了状态码的类型,后两个数字没有分类的作用。
示例性的,HTTP响应状态码共分为5种类型:1**:信息,服务器收到请求,需要请求者继续执行操作;2**:成功,操作被成功接收并处理;3**:重定向,需要进一步的操作以完成请求;4**:客户端错误,请求包含语法错误或无法完成请求;5**:服务器错误,服务器在处理请求的过程中发生了错误。在一些示例中,可预设被认为是响应错误的状态码。
步骤S406,将执行异常数据和事务错误数据作为请求对应的故障监测数据发送给服务器。
在一些实施例中,上述方法还包括:根据异常分类规则确定异常的异常类型,其中,故障监测数据还包括异常类型。在本公开实施例中,执行异常对应异常的异常类型可分为:Database Exception、NoSQL Exception、MQ Exception、External Exception、CodeException、Logged Exception、Logged Error Message(Error级别以上的Exception)。事务错误对应异常的异常类型可分为:未捕获的异常(Uncaught Exception)、被定义为业务异常的执行异常(包括:Logged Exception、Logged Error Message)。
本公开实施例还提供了一种分析应用故障原因的方法,该方法应用于服务器320,根据应用探针获取的故障检测数据分析应用故障原因。
图5为本公开实施例提供的分析应用故障原因的方法一种实施方式的流程图,如图5所示,该方法包括步骤S502至步骤S518。
步骤S502,从应用探针获取的多个故障监测数据中,获取执行异常数据和/或事务错误数据包含的异常的信息。
在本公开实施例中,执行异常数据包括异常的信息。事务错误数据包括被归类到事务错误的执行异常数据,和/或前述采集到的未捕获的异常的信息。因此,步骤S502中的异常的信息可来自事务错误数据和/或来自执行异常数据。
在本公开实施例中,可对执行异常数据和事务错误数据中异常的信息分别进行分析,也可将执行异常数据和事务错误数据中异常的信息合并分析。在实际应用中,可分别进行分析,例如,事务错误影响到用户使用,可优先对事务错误进行分析,可对事务错误数据所包含异常的信息进行分析,以获取异常发生的原因。
在本公开实施例中,可以一个或多个筛选条件选择故障监测数据,例如时间范围、请求范围等,本公开实施例对此不做限定。
在本公开实施例中,异常的信息包括:异常名称、异常消息和堆栈跟踪。同一异常名称对应于多个异常消息、堆栈跟踪。
步骤S504,对同一异常名称的异常消息进行聚类,得到异常名称对应的异常消息条目。
在本公开实施例中,可以异常名称为条件读取对应异常的异常消息,形成异常名称对应的异常消息集合。对异常消息集合中的异常消息进行聚类。
在本公开实施例中,对异常名称对应的M个异常消息进行聚类,可得到K个异常消息条目,一般地,M远远大于K。例如,对异常名称的异常消息聚类后,得到的异常消息条目为:用户名{***}不存在、转账失败{“from”:“****”,“to”:“****”,“amount”:“****”}、unknown column“diagnose_ttflag”in“field list”。
步骤S506,确定异常名称对应的异常消息条目的统计信息。
在本公开实施例中,异常消息条目的统计信息可包括异常消息条目出现的次数、百分比。该信息的分析价值在于可以快速确定该错误或异常大概的范围。
例如,一个异常名称涉及M个异常,其具有M个异常消息,聚类得到K个异常消息条目,各个异常消息条目分别对应于M1、M2、…、Mk个异常,例如,“用户名{***}不存在”这一异常消息条目是由M1个异常的异常消息聚合得到的。此时,各个异常消息条目出现的次数分别为M1、M2、…、Mk,各个异常消息条目出现的百分比为M1/M、M2/M、…、Mk/M。
示例性的,用户名{***}不存在的百分比为71%,转账失败{“from”:“****”,“to”:“****”,“amount”:“****”}的百分比为17%,unknown column“diagnose_ttflag”in“fieldlist”的百分比为12%。由此,使得应用的相关人员了解到用户名{***}不存是当前的主要异常,可优先处理该异常。
在一些示例中,还包括步骤S508,对异常消息条目对应的堆栈跟踪进行聚类,得到异常消息条目对应的方法调用分布;步骤S510,确定异常消息条目对应的方法调用分布的统计信息。
例如,一个异常名称涉及M个异常,其具有M个异常消息,聚类得到K个异常消息条目,各个异常消息条目分别对应于M1、M2、…、Mk个异常,则各个异常消息条目分别对应于M1、M2、…、Mk个堆栈跟踪。每个堆栈跟踪包括方法调用栈,例如,异常出现在方法d,其方法调用为a->b->c->d,则堆栈跟踪为:at xx.d();at xx.c();at xx.b();at xx.a()。
在本公开实施例中,堆栈跟踪进行聚类,可以得到发生异常的方法,例如,异常消息条目对应的P个堆栈跟踪,P1个异常发生在方法d上,P2个异常发生在方法c上,P3个方法发生方法b上。由此,得到发生异常的方法,以及发生异常的方法的次数(P1、P2、P3)、百分比(P1/P、P2/P、P3/P)。进一步的,发生在各个方法上的调用链也可统计出,例如,发生在方法d上的异常,其调用链包括:a->d、a->b->d、a->b->c->d等,可统计每个调用链的次数和占比。
在一些情况下,异常发生在d上,但是由e导致的,此时堆栈跟踪还包括“cause by”部分,示例性的:
at xx.d()
at xx.c()
at xx.b()
at xx.a()
cause by“名称”:“消息”
at xx.e()
at xx.d()
at xx.c()
at xx.b()
at xx.a()
上述分析了异常发生位置即方法d,在本公开实施例中,还可分析异常的根因,即对“cause by”部分进行分析。上述方法还包括步骤S512,对异常消息条目对应的堆栈跟踪中根因部分的名称和消息进行聚类,得到异常消息条目对应的根因条目;步骤S514,确定异常消息条目对应的根因条目的统计信息,该统计信息可包括次数和百分比。由此,提供了导致异常的根因的信息。
在一些示例中,上述方法还包括:步骤S516,对根因条目对应的根因堆栈跟踪进行聚类,得到根因条目对应的根因方法调用分布;步骤S518,确定根因条目对应的根因方法调用分布的统计信息,该统计信息可包括次数和百分比。
本公开实施例还提供了一种分析应用故障原因的方法,该方法应用于电子设备330。
图6为本公开实施例提供的分析应用故障原因的方法另一种实施方式的流程图,如图6所示,该方法包括步骤S602至步骤S624。
步骤S602,向服务器发送第一请求,其中,第一请求携带有用户选择的异常名称。
在本公开实施例中,可显示异常名称列表,该异常名称列表来自应用探针采集的多个故障监测数据,从该多个故障检测数据中获取执行异常数据和/或事务错误数据包含的异常的信息,得到异常名称列表。在本公开实施例中,该多个故障监测数据可由一个或多个筛选条件限定范围,例如,筛选条件可包括:时间范围、请求范围、异常类型等。
在本公开实施例中,异常名称列表中还可显示异常名称的统计信息,该统计信息包括异常名称对应异常的次数和百分比,例如,异常名称包括Exception A、ExceptionB、…、Exception N,统计信息为各个异常名称的次数和百分比,例如,Exception A、Exception B的次数分别为A1、B1,百分比为A1、B1与异常总数之比。
接收用户对异常名称列表中异常名称的选择,向用户提供该异常名称的进一步信息。选择方式包括但不限于在点击异常名称对应的按钮会超链接等,本公开实施例对此不做限定。
步骤S604,接收服务器响应于第一请求的第一响应,其中,第一响应携带有异常名称对应的异常消息条目及其统计信息,异常消息条目是对异常名称对应的异常消息进行聚类得到的。
在本公开实施例中,服务器可预先对同一异常名称对应的异常消息进行聚类,得到异常名称对应的异常消息条目,并确定异常名称对应的异常消息条目的统计信息。并存储异常名称与异常消息条目及其统计信息的对应关系。在接收到请求后,从对应关系中检索得到异常名称对应的异常消息条目及其统计信息。
在本公开实施例中,服务器可在接收到异常名称后,对该异常名称对应的异常消息进行聚类,得到该异常名称对应的异常消息条目及其统计信息。
步骤S606,通过显示器显示异常消息条目及其统计信息。
在本公开实施例中,异常消息条目的统计信息包括次数和百分比。例如,一个异常名称涉及M个异常,其具有M个异常消息,聚类得到K个异常消息条目,各个异常消息条目分别对应于M1、M2、…、Mk个异常,例如,“用户名{***}不存在”这一异常消息条目是由M1个异常的异常消息聚合得到的。此时,各个异常消息条目出现的次数分别为M1、M2、…、Mk,各个异常消息条目出现的百分比为M1/M、M2/M、…、Mk/M。
示例性的,用户名{***}不存在的百分比为71%,转账失败{“from”:“****”,“to”:“****”,“amount”:“****”}的百分比为17%,unknown column“diagnose_ttflag”in“fieldlist”的百分比为12%。由此,使得应用的相关人员了解到用户名{***}不存是当前的主要异常,可优先处理该异常。
在一些示例中,上述方法还包括步骤S608至步骤S612。
步骤S608,向服务器发送第二请求,其中,第二请求携带有用户选择的异常消息条目。
在本公开实施例中,异常消息条目可显示为超链接,接收到用户对超链接的点击,此时确定用户选择的异常消息条目,但本公开实施例并不限于此。
步骤S610,接收服务器发送的第二响应,其中,第二响应携带有方法调用分布及其统计信息,方法调用分布是对异常消息条目对应的堆栈跟踪进行聚类得到的。
在本公开实施例中,服务器可预先对异常消息条目对应的堆栈跟踪进行聚类,得到异常消息条目对应的方法调用分布及统计信息。在接收到请求后,提供异常消息条目对应的方法调用分布及统计信息。
在本公开实施例中,服务器可接收异常消息条目,然后对该异常消息条目对应的堆栈跟踪进行聚类,得到异常消息条目对应的方法调用分布及统计信息。
步骤S612,通过显示器显示方法调用分布及其统计信息。
在本公开实施例中,可显示出现异常的方法的列表及其统计信息,例如,显示各个方法出现异常的次数和百分比。该方法可展开得到方法的调用链,以及调用链的统计信息。例如,异常消息条目对应的P个堆栈跟踪,P1个异常发生在方法d上,P2个异常发生在方法c上,P3个方法发生方法b上。由此,得到发生异常的方法,以及发生异常的方法的次数(P1、P2、P3)、百分比(P1/P、P2/P、P3/P)。进一步的,发生在各个方法上的调用链也可统计出,例如,发生在方法d上的异常,其调用链包括:a->d、a->b->d、a->b->c->d等,可统计每个调用链的次数和占比。
在一些示例中,异常发生在d上,但异常是从e上传递而来的,因此e为该异常的根因,上述方法还包括步骤S614至步骤S618,实现根因分析。
步骤S614,向服务器发送第三请求,其中,第三请求携带有用户选择的异常消息条目。
步骤S616,接收服务器发送的第三响应,其中,第三响应携带有根因条目及其统计信息,根因条目是对异常消息条目对应的堆栈跟踪中根因部分的名称和消息进行聚类得到的。
在本公开实施例中,服务器可预先对异常消息条目对应的堆栈跟踪中根因部分的名称和消息进行聚类,得到异常消息条目对应的根因条目。服务器可存储异常消息条目与根因条目的对应关系。
在本公开实施例中,服务器可接收到异常消息条目后,对异常消息条目对应的堆栈跟踪中根因部分的名称和消息进行聚类,得到异常消息条目对应的根因条目。
步骤S618,通过显示器显示根因条目及其统计信息。
在一些实施例中,上述方法还包括步骤S620至步骤S624,实现根因方法调用分析。
步骤S620,向服务器发送第四请求,其中,第四请求携带有用户选择的根因条目。
步骤S622,接收服务器发送的第四响应,其中,第四响应携带有根因方法调用分布及其统计信息,根因方法调用分布是对根因条目对应的根因堆栈跟踪进行聚类得到的。
步骤S624,通过显示器显示根因方法调用分布及其统计信息。
下面对本公开的一个可选示例进行描述。
在该可选示例中,执行异常为应用程序内部发生的异常,这些异常可能引发错误,多数情况下标识程序非正常运行。执行异常的异常类型可分为:Database Exception、NoSQL Exception、MQ Exception、External Exception、Code Exception、LoggedException、Logged Error Message(Error级别以上的Exception)。应当理解,该异常类型仅作为示例性说明,在实际应用中,可根据需要对异常进行分类。
在该可选示例中,事务错误指用户在访问应用时出现的非正常响应,非正常响应影响用户使用。事务错误可包括:发生未捕获的异常(Uncaught Exception)、响应错误(HTTP Error Code)、业务错误、被定义为业务异常的执行异常(Logged Exception、LoggedError Message)。
在该可选示例中,应用探针可基于规则判断Logged Exception、Logged ErrorMessage是异常是否为事务错误,在确定异常为事务错误的情况下,将异常归类对事务错误。
在该可选示例中,每一个事务错误数据和执行异常数据的产生可都关联访问应用的用户,请求参数、上下文、业务信息(如订单号、手机号、卡号等),以及完整调用链的数据,包括数据库访问、Redis访问、消息中间件、外部API的访问,日志、ErrorMessages、ExceptionMessages、代码堆栈、主机、中间件、进程等数据。
为了解决IT系统运维过程中错误和异常分析的难题,提升用户体验,降低业务损失,用IT驱动商业,该可选示例基于全量的应用探针技术,以高效、低消耗、高准确度的方法解决错误和异常根因分析难题。
在该可选示例中,该方法包括如下方面:1)应用探针获取包括执行异常数据和事务错误数据作为请求对应的故障检测数据;2)对执行异常数据和事务错误数据分类统计汇总;3)对执行异常数据和/或事务错误数据所包含异常的异常消息进行聚合分析;4)对聚合后的异常消息进行代码堆栈分析;5)分析cause by,得出根因。
在该可选示例中,基于应用探针获取事务错误数据和执行异常数据。其中,在应用启动时,嵌入应用探针,对ExceptionHandler进行Hook;在应用运行时,获取事务错误数据和执行异常数据。
在该可选示例中,对事务错误和执行异常分类统计汇总,通过聚类算法,将采集上来的数据进行聚类汇总统计。
在该可选示例中,当针对某一个特定的事务错误和执行异常分析时,分析其异常消息(Exception Message)以判断该错误和异常。Exception Message具备多样性,因此首先对Exception Message进行分词,当分词中存在连续数字,某一段内容多次重复时,将其模糊化混淆处理,处理结果再次进行聚类分析统计。
在该可选示例中,对聚合后的Exception Message(称为异常消息条目)进行代码堆栈分析,模糊混淆后的Exception Message,已经能解决部分场景下错误和异常根因分析的需要。但可利用聚类算法分析其Stacktrace,以判断发生该异常的方法调用分布。
在该可选示例中,分析causeby,在IT软件的开发语言中,均存在Exceptionchain的概念,即异常触发的链路,可以有无限级别,前述分析的为最顶层的Exception,causeby为底层的Exception,多为异常的根因。Causeby包含的信息包括Exception名称、ExceptionMessage以及Stacktrace,因此首先将Exception名称、Exception Message合并聚类分析统计,然后分析其Stacktrace。
在该可选示例中,根据上述步骤的分析,可以得到Causeby Exception的分布,以及Stacktrace方法的分布,即可得到该错误的根因。
在该可选示例中,将执行异常数据和事务错误数据分开汇总统计。事务错误相关指标包括:请求数、每分钟请求数、错误数、每分钟错误数、错误率,如图7所示。对于事务错误的分类统计则关注各个类型的事务错误的次数,如图8所示,事务错误的类型包括未捕获的异常(Uncaught Exceptions)、响应错误(HTTP Error Codes)、业务错误,统计每分钟(但不限于此)的事务错误中各种类型的事务错数的次数。
在该可选示例中,执行异常相关指标包括异常总数、每分钟异常数;如图9所示。对于异常的分类统计则关注各个类型的异常次数,如图10所示,执行异常的类型包括:Database Exception、NoSQL Exception、MQ Exception、External Exception、CodeException、Logged Exception、Logged Error Message,统计每分钟(但不限于此)中执行异常及每种类型的执行异常的次数。
通过图7至10的统计,实现了事务错误和执行异常的趋势分析,统计的粒度到事务错误和执行异常的类型级别。在该可选示例中,详细的事务错误和异常名称的统计如图11所示,关注发生时间、持续时间,持续时长,发生次数,发生频率、占比等性能指标以及该事务错误和执行异常的业务影响指标。
在该可选示例中,为针对某一个特定事务错误和执行异常的分析。事务错误数据和执行异常数据的采集中,通常情况下,一个事务错误或执行异常的异常消息可以不同,通过对异常消息的聚合分析,将异常消息聚类为异常消息条目,来发现事务错误或执行异常发生的占比,如图12所示。该信息的分析价值在于可以快速确定该错误或异常大概的范围。
进一步的分析,可针对某一异常消息条目,进行对事务错误和/或执行异常发生时的代码堆栈(堆栈跟踪)进行分析,以锁定错误和异常发生的方法名及其行数。在该可选示例中,通过针对某一异常消息条目,分析其代码堆栈(Stack trace)。如图13所示,每一次异常和错误发生时,应用探针都或获取当前线程的Stack trace,通过对多次Stack trace的聚合分析,可以知道某一个方法出现次数的占比,通过该分析即可知道该执行异常或事务错误,是由哪个业务方法引起。
在该可选示例中,实现了一个更细致的分析。事务错误或执行异常的堆栈信息通常情况下回包含异常消息和堆栈跟踪。堆栈追踪包括异常发生时的代码堆栈和causeby部分,causeby部分是可选的,前述分析了异常消息和代码堆栈,在此选取causeby的最末端部分(即根因部分)进行分析,以确定该事务错误或执行异常的根因(Rootcause)。如图14所示。
在该可选示例中,应用探针的事务错误数据、执行异常数据采集Hook和Instrument,包括:应用探针在随着应用进程启动;通过内置的Hook和Instrument技术,首先对程序运行机制中的ExceptionHandler进行Hook处理,此步骤的目的是拦截程序运行时,当Exception发生时,应用探针能够收到对应的信号和Exception信息;对LogFrameworks进行Instrument操作,此步骤的目的是截获打印在日志中的”ERROR”级别以上Exception,包含Exceptionclass、Exceptionmessage、errormessage等信息;对应用程序的Request和Response进行Wrapper操作,此步骤的目的是,接管应用服务器(ApplicationServer)收到的请求和响应,以创建事务,维护调用链,以及管理错误、异常信息发生的Span;对Business Methods(业务方法)进行嵌码,以获取方法的出参和入参,当发生Exception时,评估Exception对业务的影响。
在该可选示例中,执行异常数据采集方法包括:依据上一个流程中对WebRequest的接管,应用探针在请求开始的时候创建事务;业务方法开始执行,采集方法描述,以该方法名命名Tracer;判断是否开启采集方法参数配置,如果为真,则采集方法的入参,否则进行后续动作;判断日志组件是否记录“ERROR“级别以上的日志,如果为真,则采集日志组件输出到内存中的Exception或ErrorMessage;在方法退出执行之前,暂存方法返回值,及捕获的异常(Catched Exception);判断是否开启采集方法返回值配置,如果为真,则采集方法的出参,否则进行后续动作;判断是否发生了Exception,如果为真,则记录Exception及Exceptionchain信息,否则进行后续动作;方法退出执行,释放返回值,关联调用链。
在该可选示例中,事务错误数据采集包括:依据应用探针事务错误数据、执行异常数据采集Hook和Instrument流程中的处理流程,应用探针对WebRequest的接管,应用探针在请求开始的时候创建事务,在请求结束,开始响应时结束事务,对Error(事务错误)进行处理;在Response(响应)开始时,判断是否发生Uncaught Exception、业务错误处理,HTTPResponse status code判断等逻辑;判断是否发生了Business Error(业务错误),如果为真,则采集Business Error;判断是否发生了Uncaught Exception,如果为真,则采集Uncaught Exception及Exceptionchain;判断HTTP Response status code,是否在HTTPError code范围内,如果为真,则生产HTTPErrorCodeXXX类型的错误;正常执行Response,流程结束。
在该可选示例中,通过应用探针采集事务错误数据和执行异常数据。先分布汇总事务错误和执行异常的趋势;再汇总分析执行异常和事务错误分类统计;进行详细的事务错误和执行异常的统计;对单个异常名称(来自事务错误数据和/或执行异常数据)进行异常消息分析,得到异常消息条目;对单个异常消息条目分析Stacktrace;对单个异常消息条目分析Causeby。实现了自动分析错误和异常的根因有效弥补IT运维研发人员在处理错误和异常故障时的技术方案空缺。通过应用探针技术获取错误和异常信息更实时高效,该分析方法可以关联调用链,该分析方法完全适配微服务场景。可以关联事务错误数据,做故障影响分析。
本公开实施例还提供了一种计算机设备。图15为本公开实施例提供的计算机设备一种实施方式的硬件结构示意图,如图15所示,本公开实施例的计算机设备10包括:至少包括但不限于:可通过系统总线相互通信连接的存储器11和处理器12。需要指出的是,图15仅示出了具有组件11-12的计算机设备10,但是应理解的是,并不要求实施所有示出的组件,可以替代的实施更多或者更少的组件。
本实施例中,存储器11(即可读存储介质)包括闪存、硬盘、多媒体卡、卡型存储器(例如,SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中,存储器11可以是计算机设备10的内部存储单元,例如计算机设备10的硬盘或内存。在另一些实施例中,存储器11也可以是计算机设备10的外部存储设备,例如该计算机设备10上配备的插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)等。当然,存储器11还可以既包括计算机设备10的内部存储单元也包括其外部存储设备。本实施例中,存储器11通常用于存储安装于计算机设备10的操作系统和各类软件。此外,存储器11还可以用于暂时地存储已经输出或者将要输出的各类数据。
处理器12在一些实施例中可以是中央处理器(Central Processing Unit,CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器12通常用于控制计算机设备10的总体操作。本实施例中,处理器12用于运行存储器11中存储的程序代码或者处理数据,例如本公开实施例的任一或多个方法。
本实施例还提供一种计算机可读存储介质,如闪存、硬盘、多媒体卡、卡型存储器(例如,SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘、服务器、App应用商城等等,其上存储有计算机程序,程序被处理器执行时实现相应功能。本实施例的计算机可读存储介质用于存储本公开实施例的任一或多个的程序代码,被处理器执行时实现本公开实施例的任一或多个的方法。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
上述本公开实施例序号仅仅为了描述,不代表实施例的优劣。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本公开各个实施例所述的方法。
上面结合附图对本公开的实施例进行了描述,但是本公开并不局限于上述的具体实施方式,上述的具体实施方式仅仅是示意性的,而不是限制性的,本领域的普通技术人员在本公开的启示下,在不脱离本公开宗旨和权利要求所保护的范围情况下,还可做出很多形式,这些均属于本公开的保护之内。

Claims (10)

1.一种监测应用的方法,其特征在于,所述应用用于响应于客户端的请求调用一个或多个业务方法以提供所述请求对应的响应,所述方法包括:
应用探针在应用接收到所述请求后,获取执行异常数据,包括:获取预设的业务方法执行中的异常的信息;
所述应用探针在所述请求的响应开始时,获取事务错误数据,包括:获取所述预设的业务方法中入口方法未捕获的异常的信息,其中,当出现入口方法未捕获的异常时产生非正常响应而导致事务错误;
所述应用探针将所述执行异常数据和所述事务错误数据作为所述请求对应的故障监测数据发送给服务器;
其中,所述异常的信息包括:异常名称、异常消息和堆栈跟踪。
2.一种分析应用故障原因的方法,应用于服务器,其特征在于,包括:
从应用的多个请求对应的故障监测数据中,获取执行异常数据和/或事务错误数据包含的异常的信息,所述异常的信息包括:异常名称和异常消息;其中,所述应用用于响应于客户端的请求调用一个或多个业务方法以提供所述请求对应的响应,所述故障监测数据来自监测所述应用的应用探针;
对同一异常名称的异常消息进行聚类,得到所述异常名称对应的异常消息条目;
确定所述异常名称对应的所述异常消息条目的统计信息,其中,所述统计信息包括:每个异常消息条目对应异常的出现次数,和/或每个异常消息条目对应异常的出现次数占所述异常名称对应异常的总次数的百分比。
3.根据权利要求2所述的方法,其特征在于,所述异常的信号还包括堆栈跟踪,所述方法还包括:
对所述异常消息条目对应的堆栈跟踪进行聚类,得到所述异常消息条目对应的方法调用分布;
确定所述异常消息条目对应的方法调用分布的统计信息。
4.根据权利要求2或3所述的方法,其特征在于,还包括:
对所述异常消息条目对应的堆栈跟踪中根因部分的名称和消息进行聚类,得到所述异常消息条目对应的根因条目;
确定所述异常消息条目对应的根因条目的统计信息。
5.根据权利要求4所述的方法,其特征在于,还包括:
对所述根因条目对应的根因堆栈跟踪进行聚类,得到所述根因条目对应的根因方法调用分布;
确定所述根因条目对应的根因方法调用分布的统计信息。
6.一种分析应用故障原因的方法,其特征在于,包括:
向服务器发送第一请求,其中,所述第一请求携带有用户选择的异常名称;
接收所述服务器响应于所述第一请求的第一响应,其中,所述服务器用于根据权利要求2所述的方法产生所述第一响应,所述第一响应携带有所述异常名称对应的异常消息条目及其统计信息,所述异常消息条目是对所述第一请求中的异常名称对应的异常消息进行聚类得到的;
通过显示器显示所述异常消息条目及其统计信息。
7.根据权利要求6所述的方法,其特征在于,还包括:
向所述服务器发送第二请求,其中,所述第二请求携带有用户选择的异常消息条目;
接收所述服务器发送的第二响应,其中,所述服务器用于根据权利要求3所述的方法产生所述第二响应,所述第二响应携带有方法调用分布及其统计信息,所述方法调用分布是对所述第二请求中的异常消息条目对应的堆栈跟踪进行聚类得到的;
通过所述显示器显示所述方法调用分布及其统计信息。
8.根据权利要求6或7所述的方法,其特征在于,还包括:
向所述服务器发送第三请求,其中,所述第三请求携带有用户选择的异常消息条目;
接收所述服务器发送的第三响应,其中,所述服务器用于根据权利要求4所述的方法产生所述第三响应,所述第三响应携带有根因条目及其统计信息,所述根因条目是对所述第三请求中的异常消息条目对应的堆栈跟踪中根因部分的名称和消息进行聚类得到的;
通过所述显示器显示所述根因条目及其统计信息。
9.根据权利要求8所述的方法,其特征在于,还包括:
向所述服务器发送第四请求,其中,所述第四请求携带有用户选择的根因条目;
接收所述服务器发送的第四响应,其中,所述服务器用于根据权利要求5所述的方法产生所述第四响应,所述第四响应携带有根因方法调用分布及其统计信息,所述根因方法调用分布是对所述第四请求中的根因条目对应的根因堆栈跟踪进行聚类得到的;
通过所述显示器显示所述根因方法调用分布及其统计信息。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有程序,所述程序被处理器执行时实现如权利要求1至9中任一项所述的方法的步骤。
CN202310133621.6A 2021-09-22 2021-09-22 一种监测、分析应用故障原因的方法及存储介质 Pending CN116107789A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310133621.6A CN116107789A (zh) 2021-09-22 2021-09-22 一种监测、分析应用故障原因的方法及存储介质

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111105762.4A CN113849330A (zh) 2021-09-22 2021-09-22 一种监测、分析应用故障原因的方法、设备及存储介质
CN202310133621.6A CN116107789A (zh) 2021-09-22 2021-09-22 一种监测、分析应用故障原因的方法及存储介质

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN202111105762.4A Division CN113849330A (zh) 2021-09-22 2021-09-22 一种监测、分析应用故障原因的方法、设备及存储介质

Publications (1)

Publication Number Publication Date
CN116107789A true CN116107789A (zh) 2023-05-12

Family

ID=78975033

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202111105762.4A Pending CN113849330A (zh) 2021-09-22 2021-09-22 一种监测、分析应用故障原因的方法、设备及存储介质
CN202310133621.6A Pending CN116107789A (zh) 2021-09-22 2021-09-22 一种监测、分析应用故障原因的方法及存储介质

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN202111105762.4A Pending CN113849330A (zh) 2021-09-22 2021-09-22 一种监测、分析应用故障原因的方法、设备及存储介质

Country Status (1)

Country Link
CN (2) CN113849330A (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11438251B1 (en) * 2022-02-28 2022-09-06 Bank Of America Corporation System and method for automatic self-resolution of an exception error in a distributed network
CN115114120B (zh) * 2022-08-29 2022-11-04 统信软件技术有限公司 进程异常监控方法和装置、计算设备和可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108683562A (zh) * 2018-05-18 2018-10-19 深圳壹账通智能科技有限公司 异常检测定位方法、装置、计算机设备及存储介质
CN109495340A (zh) * 2018-11-02 2019-03-19 国电南京自动化股份有限公司 一种Android应用性能监控统计方法及系统
CN111950573A (zh) * 2019-05-16 2020-11-17 北京小米智能科技有限公司 异常问题聚类的方法及装置
CN113407370A (zh) * 2020-03-16 2021-09-17 中国移动通信有限公司研究院 根因错误的聚类方法、装置、设备及计算机可读存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3051421B1 (en) * 2015-02-02 2020-07-01 New Relic, Inc. An application performance analyzer and corresponding method
CN108471359A (zh) * 2018-03-22 2018-08-31 政和科技股份有限公司 一种网站访问异常监控方法、装置和介质
CN109634813A (zh) * 2018-12-11 2019-04-16 平安科技(深圳)有限公司 电子装置、云平台异常确认方法及存储介质
CN111698131B (zh) * 2020-06-10 2021-10-08 中国工商银行股份有限公司 信息处理方法、装置、电子设备和介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108683562A (zh) * 2018-05-18 2018-10-19 深圳壹账通智能科技有限公司 异常检测定位方法、装置、计算机设备及存储介质
CN109495340A (zh) * 2018-11-02 2019-03-19 国电南京自动化股份有限公司 一种Android应用性能监控统计方法及系统
CN111950573A (zh) * 2019-05-16 2020-11-17 北京小米智能科技有限公司 异常问题聚类的方法及装置
CN113407370A (zh) * 2020-03-16 2021-09-17 中国移动通信有限公司研究院 根因错误的聚类方法、装置、设备及计算机可读存储介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
毛澄映: "《软件维护中风险分析与故障管理策略研究》", 合肥:中国科学技术大学出版社, pages: 127 - 128 *

Also Published As

Publication number Publication date
CN113849330A (zh) 2021-12-28

Similar Documents

Publication Publication Date Title
CN108647891B (zh) 数据异常归因分析方法及装置
CN110874778A (zh) 异常订单检测方法及装置
US20180046956A1 (en) Warning About Steps That Lead to an Unsuccessful Execution of a Business Process
CN114185708A (zh) 基于分布式链路追踪的数据分析方法、装置和电子设备
CN116107789A (zh) 一种监测、分析应用故障原因的方法及存储介质
CN108156141B (zh) 一种实时数据识别方法、装置及电子设备
CN109992473B (zh) 应用系统的监控方法、装置、设备及存储介质
CN112152823B (zh) 网站运行错误监控方法、装置及计算机存储介质
JP6920378B2 (ja) 再修理用基板の検出装置、方法およびコンピュータ読み取り可能な記憶媒体
CN109544014B (zh) 基于历史数据回放的反欺诈方法及装置
CN113746703A (zh) 一种异常链路监控方法、系统和装置
CN114595765A (zh) 数据处理方法、装置、电子设备及存储介质
CN111506455B (zh) 服务发布结果的查验方法及装置
CN111737080A (zh) 异常交易嫌疑的监测方法、装置、计算机设备和存储介质
CN111784176A (zh) 一种数据处理方法、装置、服务器及介质
CN114880194B (zh) 服务异常监控方法、装置、电子设备及计算机存储介质
CN116738091A (zh) 页面监控方法、装置、电子设备及存储介质
CN110704273A (zh) 配置信息的处理方法和装置、电子设备和存储介质
CN113934595A (zh) 数据分析方法及系统、存储介质及电子终端
CN113468076A (zh) 应用程序的异常测试方法、装置、设备及存储介质
CN113656247A (zh) 一种服务监控方法、装置、电子设备及可读存储介质
CN113450208A (zh) 贷款风险变动预警、模型训练方法和装置
CN112651660A (zh) 企业风险预警方法及装置
CN111681005A (zh) 数据交互方法、装置和电子设备
CN111835566A (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