一种应用系统的故障分析方法及装置与流程

1.本发明实施例涉及信息技术技术领域，尤其涉及一种应用系统的故障分析方法、装置、计算设备及计算机可读存储介质。


背景技术：

2.现有的故障分析装置一般为找出告警事件直接的特征关系或基于历史告警信息处理方法形成推理网络来确定告警事件是否为故障根因，从而对产生该告警事件的应用系统是否发生故障进行判断。告警事件的产生也是应用系统在业务执行层面发生执行失败后产生的，是一种被动的告警方法。
3.上述方法中，产生告警事件为基于应用层产生的被动告警，不能准确及时且主动地发现告警事件，且仅能针对应用系统是否发生故障做出判断。然而应用系统中部署的层级十分复杂，采用现有的故障分析方法不能准确地判断出是应用系统的哪个层级发生了故障，不能深入到具体的故障点。
4.综上，本发明实施例提供一种应用系统的故障分析方法，用以准确定位应用系统的故障点。


技术实现要素：

5.本发明实施例提供一种应用系统的故障分析方法，用以准确定位应用系统的故障点。
6.第一方面，本发明实施例提供一种应用系统的故障分析方法，包括：
7.获取应用系统在运行过程中产生的各调用链日志；
8.基于调用链监控项，确定各调用链日志是否满足告警规则；所述调用链监控项用于表征调用链日志中的被调用方信息；
9.将满足告警规则的调用链日志中的调用链监控项作为告警数据；
10.按照所述调用链监控项所表征的各维度对各告警数据进行分析，确定所述应用系统的故障点；所述各维度包括主机维度、子系统维度、服务维度和方法维度中的至少一项。
11.应用系统在运行过程中会产生各层级之间的调用，每次调用都会产生调用链日志，通过调用链监控项，可以将满足告警规则的各调用链日志确定出来，作为告警数据。可以发现，告警数据的产生不是依赖于应用系统基于应用层的告警产生，而是通过调用链日志，主动确定的。如此确定的告警数据更加准确和及时。再按照调用链监控项所表征的各维度对各告警数据进行分析，确定应用系统的故障点，这里的各维度涉及到应用系统的各维度，最终确定的故障点也是应用系统的各维度，可以准确定位应用系统的具体的故障点。实现快速的发现和处理故障，提高运维效率。且不依赖于历史告警信息，而是结合当前整个应用系统的运行情况确定故障点，更具准确性。
12.可选地，所述调用链监控项所表征的维度包括主机维度；
13.按照所述调用链监控项所表征的各维度对各告警数据进行分析，确定所述应用系
统的故障点，包括：
14.针对各告警数据中的任一告警主机，确定在所述各告警数据中所述告警主机关联的告警服务的第一数量；根据所述告警主机上运行的所有服务的第二数量及所述第一数量，确定所述告警主机是否为所述应用系统的故障点。
15.通过告警主机关联的告警服务的占比来确定告警主机是否为故障点，更具准确性。
16.可选地，所述调用链监控项所表征的维度还包括服务维度；
17.根据所述告警主机上运行的所有服务的第二数量及所述第一数量，确定所述告警主机是否为所述应用系统的故障点，包括：
18.在所述第一数量与第二数量之间的第一预设关系大于第一预设阈值，则确定所述告警主机为所述应用系统的故障点；
19.在所述第一预设关系不大于所述第一预设阈值，则确定所述告警主机的告警服务为所述应用系统的故障点。
20.具体地，在告警主机关联的告警服务的占比与第一预设阈值的关系不同时，给出不同的故障点的判断，更具准确性。
21.可选地，所述调用链监控项所表征的维度还包括子系统维度；
22.确定所述告警主机是否为所述应用系统的故障点之后，还包括：
23.针对确定为故障点的各告警主机，确定各告警主机所属的各子系统；针对任一子系统，若属于所述子系统的告警主机的第三数量与属于所述子系统的全部主机的第四数量之间的第二预设关系满足第二预设阈值，则确定所述子系统为所述应用系统的故障点。
24.在确定故障点为告警主机后，我们还可以进一步判断该告警主机的故障是否是由于子系统的故障引起，因此可以继续判断子系统是否故障。对告警主机所属的子系统的告警主机的占比的判断可以帮助确定子系统是否为故障点。
25.可选地，所述调用链监控项所表征的维度包括服务维度；
26.按照所述调用链监控项所表征的各维度对各告警数据进行分析，确定所述应用系统的故障点，包括：
27.针对各告警数据中的任一告警服务，确定在所述各告警数据中所述告警服务关联的告警主机的第五数量；确定所述第五数量与运行所述告警服务的所有主机的第六数量之间的第三预设关系；在所述第三预设关系大于第三预设阈值时，确定所述告警服务为所述应用系统的故障点。
28.通过告警服务关联的告警主机的占比，确定告警服务是否确实为故障点，提高了判断告警服务为故障点的准确性。
29.可选地，所述调用链监控项所表征的维度包括方法维度；
30.按照所述调用链监控项所表征的各维度对各告警数据进行分析，确定所述应用系统的故障点，包括：
31.针对各告警数据中的任一告警方法，基于同一告警主机中的第七数量和第八数量，确定所述告警方法是否为所述应用系统的故障点；所述第七数量用于表征告警主机中运行的所述告警方法所属服务下的各告警方法的数量；所述第八数量用于表征告警主机中运行的所述告警方法所属服务下的所有方法的数量。
32.如此，可以准确地确定某告警方法是否为应用系统的故障点。
33.可选地，基于同一告警主机中的第七数量和第八数量，确定所述告警方法是否为所述应用系统的故障点，包括：
34.在所述第七数量与第八数量之间的第四预设关系大于第四预设阈值，且运行所述告警方法所属服务的告警主机的第九数量和运行所述告警方法所属服务的所有主机的第十数量之间的第五预设关系不大于第五预设阈值，则确定所述告警主机上运行的所述告警方法所属服务为所述应用系统的故障点。
35.可选地，基于同一告警主机中的第七数量和第八数量，确定所述告警方法是否为所述应用系统的故障点，包括：
36.在所述第七数量与第八数量之间的第四预设关系大于第四预设阈值，且运行所述告警方法所属服务的告警主机的第九数量和运行所述告警方法所属服务的所有主机的第十数量之间的第五预设关系大于第五预设阈值，则确定运行的所述告警方法所属服务为所述应用系统的故障点。
37.可选地，基于同一告警主机中的第七数量和第八数量，确定所述告警方法是否为所述应用系统的故障点，包括：
38.在所述第七数量与第八数量之间的第四预设关系不大于第四预设阈值，且运行所述告警方法的告警主机的第十一数量和运行所述告警方法的所有主机的第十二数量之间的第六预设关系大于第六预设阈值，则确定所述告警方法为所述应用系统的故障点。
39.可选地，基于同一告警主机中的第七数量和第八数量，确定所述告警方法是否为所述应用系统的故障点，包括：
40.在所述第七数量与第八数量之间的第四预设关系不大于第四预设阈值，且运行所述告警方法的告警主机的第十一数量和运行所述告警方法所属服务的所有主机的第十二数量之间的第六预设关系不大于第六预设阈值，则确定所述告警主机上运行的所述告警方法为所述应用系统的故障点。
41.可选地，还包括：
42.基于各调用链日志，以子系统为维度，生成子系统的调用关系图；所述子系统的调用关系图中具有作为故障点的子系统的指示信息；和/或，
43.基于各调用链日志，以服务为维度，生成服务的调用关系图；所述服务的调用关系图中具有作为故障点的服务的指示信息。
44.基于各调用链日志，可以生成子系统的调用关系图和/或服务的调用关系图，供用户查看，依据清晰明确的调用关系图，用户也可以获取更多调用信息，方便依据故障节点做出优化，更快的排除故障。
45.第二方面，本发明实施例还提供一种应用系统的故障分析装置，包括：
46.获取单元，用于获取应用系统在运行过程中产生的各调用链日志；
47.确定单元，用于基于调用链监控项，确定各调用链日志是否满足告警规则；所述调用链监控项用于表征调用链日志中的被调用方信息；
48.将满足告警规则的调用链日志中的调用链监控项作为告警数据；
49.处理单元，用于按照所述调用链监控项所表征的各维度对各告警数据进行分析，确定所述应用系统的故障点；所述各维度包括主机维度、子系统维度、服务维度和方法维度
中的至少一项。
50.可选地，所述调用链监控项所表征的维度包括主机维度；
51.所述处理单元，具体用于：
52.针对各告警数据中的任一告警主机，确定在所述各告警数据中所述告警主机关联的告警服务的第一数量；根据所述告警主机上运行的所有服务的第二数量及所述第一数量，确定所述告警主机是否为所述应用系统的故障点。
53.可选地，所述调用链监控项所表征的维度还包括服务维度；
54.所述处理单元，具体用于：
55.在所述第一数量与第二数量之间的第一预设关系大于第一预设阈值，则确定所述告警主机为所述应用系统的故障点；
56.在所述第一预设关系不大于所述第一预设阈值，则确定所述告警主机的告警服务为所述应用系统的故障点。
57.可选地，所述调用链监控项所表征的维度还包括子系统维度；
58.所述处理单元，还用于：
59.针对确定为故障点的各告警主机，确定各告警主机所属的各子系统；针对任一子系统，若属于所述子系统的告警主机的第三数量与属于所述子系统的全部主机的第四数量之间的第二预设关系满足第二预设阈值，则确定所述子系统为所述应用系统的故障点。
60.可选地，所述调用链监控项所表征的维度包括服务维度；
61.所述处理单元，具体用于：
62.针对各告警数据中的任一告警服务，确定在所述各告警数据中所述告警服务关联的告警主机的第五数量；确定所述第五数量与运行所述告警服务的所有主机的第六数量之间的第三预设关系；在所述第三预设关系大于第三预设阈值时，确定所述告警服务为所述应用系统的故障点。
63.可选地，所述调用链监控项所表征的维度包括方法维度；
64.所述处理单元，具体用于：
65.针对各告警数据中的任一告警方法，基于同一告警主机中的第七数量和第八数量，确定所述告警方法是否为所述应用系统的故障点；所述第七数量用于表征告警主机中运行的所述告警方法所属服务下的各告警方法的数量；所述第八数量用于表征告警主机中运行的所述告警方法所属服务下的所有方法的数量。
66.可选地，所述处理单元，具体用于：
67.在所述第七数量与第八数量之间的第四预设关系大于第四预设阈值，且运行所述告警方法所属服务的告警主机的第九数量和运行所述告警方法所属服务的所有主机的第十数量之间的第五预设关系不大于第五预设阈值，则确定所述告警主机上运行的所述告警方法所属服务为所述应用系统的故障点。
68.可选地，所述处理单元，具体用于：
69.在所述第七数量与第八数量之间的第四预设关系大于第四预设阈值，且运行所述告警方法所属服务的告警主机的第九数量和运行所述告警方法所属服务的所有主机的第十数量之间的第五预设关系大于第五预设阈值，则确定运行的所述告警方法所属服务为所述应用系统的故障点。
70.可选地，所述处理单元，具体用于：
71.在所述第七数量与第八数量之间的第四预设关系不大于第四预设阈值，且运行所述告警方法的告警主机的第十一数量和运行所述告警方法的所有主机的第十二数量之间的第六预设关系大于第六预设阈值，则确定所述告警方法为所述应用系统的故障点。
72.可选地，所述处理单元，具体用于：
73.在所述第七数量与第八数量之间的第四预设关系不大于第四预设阈值，且运行所述告警方法的告警主机的第十一数量和运行所述告警方法所属服务的所有主机的第十二数量之间的第六预设关系不大于第六预设阈值，则确定所述告警主机上运行的所述告警方法为所述应用系统的故障点。
74.可选地，所述处理单元，还用于：
75.基于各调用链日志，以子系统为维度，生成子系统的调用关系图；所述子系统的调用关系图中具有作为故障点的子系统的指示信息；和/或，
76.基于各调用链日志，以服务为维度，生成服务的调用关系图；所述服务的调用关系图中具有作为故障点的服务的指示信息。
77.第三方面，本发明实施例还提供一种计算设备，包括：
78.存储器，用于存储计算机程序；
79.处理器，用于调用所述存储器中存储的计算机程序，按照获得的程序执行上述任一方式所列的应用系统的故障分析方法。
80.第四方面，本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行程序，所述计算机可执行程序用于使计算机执行上述任一方式所列的应用系统的故障分析方法。
附图说明
81.为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
82.图1为本发明实施例提供的一种系统架构的示意图；
83.图2为本发明实施例提供的一种应用系统的故障分析方法的流程示意图；
84.图3为本发明实施例提供的一种典型的mesh架构调用链的示意图；
85.图4为本发明实施例提供的一种确定应用系统的故障点的整体方案的示意图；
86.图5为本发明实施例提供的一种故障分析装置的内部功能架构的示意图；
87.图6为本发明实施例提供的一种可能的调用链关系图；
88.图7为本发明实施例提供的一种可能的初始的应用状态看板的示意图；
89.图8为本发明实施例提供的一种可能的子系统调用链的显示界面的示意图；
90.图9为本发明实施例提供的一种可能的服务调用链的显示界面的示意图；
91.图10为本发明实施例提供的一种可能的调用明细的显示界面的示意图；
92.图11为本发明实施例提供的一种可能的根因分析的显示界面的示意图；
93.图12为本发明实施例提供的一种更加细化的故障分析装置的内部功能架构的示
意图；
94.图13为本发明实施例提供的一种应用系统的故障分析装置的结构示意图；
95.图14为本发明实施例提供的一种计算机设备的结构示意图。
具体实施方式
96.为使本技术的目的、实施方式和优点更加清楚，下面将结合本技术示例性实施例中的附图，对本技术示例性实施方式进行清楚、完整地描述，显然，所描述的示例性实施例仅是本技术一部分实施例，而不是全部的实施例。
97.基于本技术描述的示例性实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术所附权利要求保护的范围。此外，虽然本技术中公开内容按照示范性一个或几个实例来介绍，但应理解，可以就这些公开内容的各个方面也可以单独构成一个完整实施方式。
98.需要说明的是，本技术中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本技术的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。
99.本技术中说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明(unless otherwise indicated)。应该理解这样使用的用语在适当情况下可以互换，例如能够根据本技术实施例图示或描述中给出那些以外的顺序实施。
100.此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的那些组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。
101.图1示例性的示出了本发明实施例所适用的一种系统架构，该系统架构可以为服务器100，包括处理器110、通信接口120和存储器130。
102.其中，通信接口120用于与终端设备进行通信，收发该终端设备传输的信息，实现通信。
103.处理器110是服务器100的控制中心，利用各种接口和路线连接整个服务器100的各个部分，通过运行或执行存储在存储器130内的软件程序/或模块，以及调用存储在存储器130内的数据，执行服务器100的各种功能和处理数据。可选地，处理器110可以包括一个或多个处理单元。
104.存储器130可用于存储软件程序以及模块，处理器110通过运行存储在存储器130的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器130可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据业务处理所创建的数据等。此外，存储器130可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
105.需要说明的是，上述图1所示的结构仅是一种示例，本发明实施例对此不做限定。
106.图1所示的服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络
服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(content delivery network，cdn)、以及大数据和人工智能平台等基础云计算服务的云服务器。
107.现有的故障分析装置一般为找出告警事件直接的特征关系或基于历史告警信息处理方法形成推理网络来确定告警事件是否为故障根因，从而对产生该告警事件的应用系统是否发生故障进行判断。告警事件的产生也是应用系统在业务执行层面发生执行失败后产生的，是一种被动的告警方法。
108.华为公司cn110609759 a专利描述了根据第一告警事件和其他告警事件之间的关系的特征向量来判断第一告警事件是否为根因告警事件。该方法主要基于对生产告警事件的溯源分析，只能依赖事后的被动告警事件。
109.深圳前海微众银行cn 111106953 a专利公开了一种异常根因分析的方法及装置，通过将告警日志转化成事实信息放入推理网络中进行匹配，所述推理网络是根据历史告警的事实信息得到各判决路径且根据历史告警的分析结果得到各判决路径对应的执行策略，依赖于历史经验数据。
110.上述方法中，产生告警事件均为基于应用层产生的被动告警，不能准确及时且主动地发现告警事件，且仅能针对应用系统是否发生故障做出判断。然而应用系统中部署的层级十分复杂，采用现有的故障分析方法不能准确地判断出是应用系统的哪个层级发生了故障，不能深入到具体的故障点。
111.伴随着应用系统的功能逐渐丰富壮大，应用系统的结构日趋复杂，通常应用系统根据业务功能划分为多层次、多模块，每一层里面又都有大量的服务和方法调用。例如对于收单系统，包括前置子系统、网关子系统、加密服务子系统、通讯子系统等，每个子系统的任务由多个主机执行，主机在执行的过程中依赖于对服务中的方法的调用，同时，不同主机之间也会产生服务的方法的调用。可以看出调用关系中涉及到应用系统的很多层级。一旦应用系统运行出现问题，运维人员很难快速判断是应用系统的哪一层级出现了问题或者是哪一层级和哪一层级交互之间有问题。
112.综上，在应用系统出现故障时，实现快速且准确地定位应用系统的故障点，提高运维效率，成为了技术难点。
113.本发明实施例提供一种应用系统的故障分析方法，如图2所示，包括：
114.步骤201，获取应用系统在运行过程中产生的各调用链日志。
115.应用系统在运行过程中为执行一个任务会产生各种调用，形成一个调用链，执行多个任务就会产生多个调用链。每一次调用都会在被调用方产生一条调用链日志，调用链日志中可以包含如下任意一项或多项：调用链全局唯一标识traceid、调用方信息、被调用方信息、调用日志产生的时间、本次调用耗时和调用是否成功等信息，例如一条调用链日志如表1：
116.表1
[0117][0118]
应用系统包括多个子系统，每个子系统又运行在多个主机中，主机中部署有服务，服务下有各方法。在各主机中设置日志代理agent，当产生调用链日志后，可以将调用链日志上传至kafka集群或其他集群中，本发明实施例对此不作限制。
[0119]
步骤202，基于调用链监控项，确定各调用链日志是否满足告警规则；所述调用链监控项用于表征调用链日志中的被调用方信息。
[0120]
调用链监控项可以为数据中心 系统 子系统 主机 服务 方法，也可以为数据中心 系统 子系统 主机 服务等，本发明实施例对此不作限制。
[0121]
若调用链监控项为数据中心 系统 子系统 主机 服务 方法，则依据该调用链监控项，将各调用链日志整理到方法粒度。将被调用方为数据中心1的系统1的子系统1的主机1的服务1的方法1的调用链日志集合，将被调用方为数据中心1的系统1的子系统1的主机1的服务1的方法2的调用链日志集合，将被调用方为数据中心1的系统1的子系统1的主机2的服务1的方法1的调用链日志集合，将被调用方为数据中心2的系统2的子系统1的主机5的服务1的方法1的调用链日志集合
……
这里不再一一列举。
[0122]
确定任一调用链监控项下的各调用链日志是否满足告警规则，告警规则可以为调用成功，或，耗时小于某一阈值等。例如某一调用链监控项下的各调用链日志中出现调用不成功的日志数量大于5，则将该调用链监控项作为告警数据。
[0123]
步骤203，将满足告警规则的调用链日志中的调用链监控项作为告警数据。
[0124]
若调用链监控项下的各调用链日志满足告警规则，则将该调用链监控项作为告警数据。例如，得到的告警数据可以为：数据中心1的系统1的子系统1的主机1的服务1的方法1、数据中心1的系统1的子系统1的主机1的服务2等。
[0125]
步骤204，按照所述调用链监控项所表征的各维度对各告警数据进行分析，确定所述应用系统的故障点；所述各维度包括主机维度、子系统维度、服务维度和方法维度中的至少一项。
[0126]
现在主流系统均已基于service mesh架构进行部署，对于这样的复杂架构系统，包含多个子系统，每个子系统包含多台主机，每台主机有若干服务进程，服务又是由若干方法组成的，节点与节点之间通过边车通讯组成了复杂调用链关系。当某主机故障时，会导致该台主机上的所有服务、方法不可用。当某服务故障时，会导致该服务对应的所有方法不可用。所以，当某节点告警或多个节点同时告警时，需定位具体的根因故障节点，比如判断是主机故障还是某些主机上的服务出现了故障。
[0127]
图3示出了一种典型的mesh架构调用链，可以看出，服务和边车通讯是分开的。本发明实施例利用边车通讯获取了应用系统中各细粒度的调用关系，基于这种通讯层的调用关系，可以主动发现调用失败，从而及时准确地确定告警数据。这与现有技术中依赖于应用系统的应用层的告警从而确定告警事件的方式具有本质的不同。
[0128]
下面通过几个具体的实施例，介绍从子系统、主机、服务、方法的维度对应用系统的故障点进行分析的方法。
[0129]
实施例一
[0130]
所述调用链监控项所表征的维度包括主机维度；按照所述调用链监控项所表征的各维度对各告警数据进行分析，确定所述应用系统的故障点，包括：
[0131]
针对各告警数据中的任一告警主机，确定在所述各告警数据中所述告警主机关联的告警服务的第一数量；根据所述告警主机上运行的所有服务的第二数量及所述第一数量，确定所述告警主机是否为所述应用系统的故障点。
[0132]
举个例子，在各告警数据中可以提取各告警主机，针对任一告警主机，确定该告警主机上部署的所有服务的第二数量，并确定该告警主机上的告警服务的第一数量，通过对第一数量和第二数量之间的关系进行分析，可以得到告警主机是否为应用系统的故障点。这里第一数量和第二数量之间的关系可以为比值的关系，也可以为差的关系，对此不作限制。
[0133]
若第一数量和第二数量的第一预设关系(例如为比值)大于第一预设阈值，则说明该告警主机上的大部分服务发生告警，那么确定告警主机为应用系统的故障点。我们将确定为故障点的告警主机的集合命名为主机集。
[0134]
若第一数量和第二数量的第一预设关系不大于第一预设阈值，则说明该告警主机上只有一小部分服务发生告警，那么确定该告警主机没有故障，而是告警主机上的告警服务为应用系统的故障点。
[0135]
例如，告警主机1上运行有10个服务，其中2个服务为告警服务，分别为告警服务1、告警服务2。第一数量和第二数量的第一预设关系为2/10，小于第一预设阈值，那么确定故障节点为告警主机1的告警服务1、告警主机1的告警服务2。若大于第一预设阈值，则告警主机1为应用系统的故障点。
[0136]
确定了多个告警主机为故障点，那么这些告警主机的集合命名为主机集。
[0137]
可选地，在确定告警主机上的告警服务为故障点之前，还可判断该告警主机的告警服务是否存在于服务集中、方法集、主机 方法集中，若否，则将告警主机的告警服务确定为故障点。服务集是指确定告警服务为故障点的集合，方法集是指确定告警服务的告警方法为故障点的集合，主机 方法集是指确定告警主机的告警服务的告警方法为故障点的集合。
[0138]
例如，若通过上述方法确定故障节点为告警主机1的告警服务1、告警主机1的告警服务2，服务集中确定告警服务1为故障点，那么优先认定告警服务1故障，剔除告警主机1的告警服务1，最终得到的结果为：告警主机1的告警服务2为故障点；
[0139]
例如，若通过上述方法确定故障节点为告警主机1的告警服务1、告警主机1的告警服务2，方法集中确定告警服务1的告警方法1为故障点，那么优先认定告警服务1的告警方法1故障，剔除告警主机1的告警服务1，最终得到的结果为：告警主机1的告警服务2为故障点；
[0140]
例如，若通过上述方法确定故障节点为告警主机1的告警服务1、告警主机1的告警服务2，主机 方法集中确定告警主机1的告警服务1的告警方法1为故障点，那么优先认定告警主机1的告警服务1的告警方法1故障，剔除告警主机1的告警服务1，最终得到的结果为：
告警主机1的告警服务2为故障点。
[0141]
以上剔除操作是为了使最终得到的故障点之间尽量不重复，方便运维人员更加直观地明确故障点，更快排除故障。
[0142]
服务集、方法集和主机 方法集中的数据的具体的确定方法在下文中详述。其中，服务集的确定方法在实施例二中，方法集和主机 方法集的确定方法在实施例三中。
[0143]
可选地，调用链监控项所表征的维度还包括子系统维度；
[0144]
确定所述告警主机是否为所述应用系统的故障点之后，还包括：
[0145]
针对确定为故障点的各告警主机，确定各告警主机所属的各子系统；针对任一子系统，若属于所述子系统的告警主机的第三数量与属于所述子系统的全部主机的第四数量之间的第二预设关系满足第二预设阈值，则确定所述子系统为所述应用系统的故障点。
[0146]
在确定故障点为告警主机后，我们还可以进一步判断该告警主机的故障是否是由于子系统的故障引起，因此可以继续判断子系统是否故障。举个例子，已经确定告警主机1为故障节点，获取告警主机1所属的子系统为子系统1，获取子系统1中有主机10台，告警主机7台，那么第三数量和第四数量的比值为7/10，若小于第二预设阈值，则说明子系统没有出现故障，仅仅为告警主机1的故障；若第三数量和第四数量的比值不小于第二预设阈值，则说明子系统1很可能出现故障，不仅会输出告警主机1为故障点，还会输出子系统1为故障点。
[0147]
实施例二
[0148]
所述调用链监控项所表征的维度包括服务维度；
[0149]
按照所述调用链监控项所表征的各维度对各告警数据进行分析，确定所述应用系统的故障点，包括：
[0150]
针对各告警数据中的任一告警服务，确定在所述各告警数据中所述告警服务关联的告警主机的第五数量；确定所述第五数量与运行所述告警服务的所有主机的第六数量之间的第三预设关系；在所述第三预设关系大于第三预设阈值时，确定所述告警服务为所述应用系统的故障点。
[0151]
在各告警数据中可以提取出各告警服务，例如提取到的告警服务为告警服务1、告警服务2。对于告警服务1，确定告警服务1部署在多少台主机上，得到第六数量；其中有多少台主机发生告警，得到第五数量。若第五数量和第六数量的第三预设关系较大，大于第三预设阈值，则说明很有可能是告警服务1的问题，导致如此高比例的主机都发生告警，因此确定告警服务1为故障点。
[0152]
若不大于第三预设阈值，则说明告警服务1没有导致大部分的主机发生告警，因此告警服务1很可能不是故障点。
[0153]
同理，可以确定告警服务2是否为故障点。
[0154]
可选地，在确定某个告警服务是故障点之前，还可判断该告警服务是否存在于方法集中，若否，则将该告警服务确定为故障点，若是，则不将该告警服务确定为故障点。
[0155]
举个例子，若方法集中已经确定告警服务1的告警方法1为故障点，那么我们认为服务1之所以会出现告警，是由于少数的方法故障导致，即在本例中是由于告警方法1导致，因此优先认定方法集中的告警服务1的告警方法1为故障点，而不再将告警服务1确定为故障点。
[0156]
可选地，在确定某个告警服务是故障点之前，还可判断该告警服务部署的全部主机是否均存在于主机集中(实施例一中介绍了确定主机集的方法)，若是，则不再将该告警服务确定为故障点，若否，则将该告警服务确定为故障点。
[0157]
例如，告警服务1部署在2个主机上，分别为主机1和主机2，若主机1和主机2均存在于实施例一中确定的主机集中，则为了避免重复，优先认定主机1和主机2为故障节点。不再将告警服务1确定为故障节点。
[0158]
将确定为故障点的告警服务的集合命名为服务集。
[0159]
实施例三
[0160]
所述调用链监控项所表征的维度包括方法维度；
[0161]
按照所述调用链监控项所表征的各维度对各告警数据进行分析，确定所述应用系统的故障点，包括：
[0162]
针对各告警数据中的任一告警方法，基于同一告警主机中的第七数量和第八数量，确定所述告警方法是否为所述应用系统的故障点；所述第七数量用于表征告警主机中运行的所述告警方法所属服务下的各告警方法的数量；所述第八数量用于表征告警主机中运行的所述告警方法所属服务下的所有方法的数量。
[0163]
举个例子，针对告警主机1的告警服务1，确定告警主机1的告警服务1中的告警方法的个数，即第七数量，确定告警主机1的告警服务1的所有方法的个数，即第八数量，根据第七数量和第八数量的比值、差值等关系，确定告警方法是否为应用系统的故障点。
[0164]
具体为：
[0165]
(1)在所述第七数量与第八数量之间的第四预设关系大于第四预设阈值，且运行所述告警方法所属服务的告警主机的第九数量和运行所述告警方法所属服务的所有主机的第十数量之间的第五预设关系不大于第五预设阈值，则确定所述告警主机上运行的所述告警方法所属服务为所述应用系统的故障点。
[0166]
(2)在所述第七数量与第八数量之间的第四预设关系大于第四预设阈值，且运行所述告警方法所属服务的告警主机的第九数量和运行所述告警方法所属服务的所有主机的第十数量之间的第五预设关系大于第五预设阈值，则确定运行的所述告警方法所属服务为所述应用系统的故障点。
[0167]
(3)在所述第七数量与第八数量之间的第四预设关系不大于第四预设阈值，且运行所述告警方法的告警主机的第十一数量和运行所述告警方法的所有主机的第十二数量之间的第六预设关系大于第六预设阈值，则确定所述告警方法为所述应用系统的故障点。
[0168]
(4)在所述第七数量与第八数量之间的第四预设关系不大于第四预设阈值，且运行所述告警方法的告警主机的第十一数量和运行所述告警方法所属服务的所有主机的第十二数量之间的第六预设关系不大于第六预设阈值，则确定所述告警主机上运行的所述告警方法为所述应用系统的故障点。
[0169]
下面按照顺序对上述4点举例说明。
[0170]
例1
[0171]
针对告警主机1的告警服务1，若共有10个方法，发生告警的方法有6个，若第四预设关系大于第四预设阈值，说明告警主机1的告警服务1中的大部分方法都发生了告警，则该告警主机1的告警服务1很可能有故障。进一步判断该告警服务1部署在10台主机上，其中
5台主机发生了告警，若不大于第五预设阈值，则说明不是告警服务1的故障，确实是告警主机1的告警服务1的故障。即告警服务1是由于部署在告警主机1上，才告警的。确定告警主机1的告警服务1为故障点。
[0172]
可选地，在确定告警主机上运行的所述告警方法所属服务为所述应用系统的故障点之前，还可判断该告警主机上运行的所述告警方法所属服务是否存在于主机集中，若存在，则不将告警主机上运行的所述告警方法所属服务确定为所述应用系统的故障点。
[0173]
举个例子，若在上述例子中确定告警主机1的告警服务1可能为故障点，但是主机集中存在告警主机1，说明告警主机1已被确定为故障点。一般来说，主机故障，那么部署在主机上的服务一定故障，但是某个服务故障，不一定导致主机故障。因此优先认定告警主机1为故障点。不再将告警主机1的告警服务1确定为故障点。
[0174]
例2
[0175]
针对告警主机1的告警服务1，若共有10个方法，发生告警的方法有6个，若第四预设关系大于第四预设阈值，说明告警主机1的告警服务1中的大部分方法都发生了告警，则该告警主机1的告警服务1很可能有故障。进一步判断该告警服务1部署在10台主机上，其中5台主机发生了告警，若大于第五预设阈值，则说明很可能是告警服务1的故障。因此确定告警服务1为故障点。
[0176]
例3
[0177]
针对告警主机1的告警服务1，若共有10个方法，发生告警的方法有6个，若第四预设关系不大于第四预设阈值，则说明告警主机1的告警服务1没有故障，进一步判断具体的故障点。针对告警主机1的告警服务1的任一告警方法，例如，告警主机1的告警服务1的告警方法1，判断该告警方法部署在多少主机上，即第十二数量，判断这些主机中告警主机的数量，即第十一数量，得到第六预设关系，若第六预设关系大于第六预设阈值，则很可能是告警方法的问题，因此将告警服务1的告警方法1确定为故障点。
[0178]
得到的确定为故障点的各告警服务的告警方法的集合为方法集。
[0179]
例4
[0180]
针对告警主机1的告警服务1，若共有10个方法，发生告警的方法有6个，若第四预设关系不大于第四预设阈值，则说明告警主机1的告警服务1没有故障，进一步判断具体的故障点。针对告警主机1的告警服务1的任一告警方法，例如，告警主机1的告警服务1的告警方法1，判断该告警方法部署在多少主机上，即第十二数量，判断这些主机中告警主机的数量，即第十一数量，得到第六预设关系，若第六预设关系不大于第六预设阈值，则我们不能将故障归因于告警方法1，仅仅是该台告警主机的告警方法的故障。因此将告警主机1的告警服务1的告警方法1确定为故障点。
[0181]
得到的确定为故障点的各告警主机的告警服务的告警方法的集合为主机 方法集。
[0182]
可选地，在将(2)得到的告警服务确定为故障点之前，可以将这些告警服务与实施二中得到的告警服务合并，一起判断任一告警服务部署的全部主机是否均存在于主机集中(实施例一中介绍了确定主机集的方法)，若是，则不再将该告警服务确定为故障点，若否，则将该告警服务确定为故障点。
[0183]
为了方便理解，图4中示出了本发明实施例提供的确定应用系统的故障点的整体
方案。
[0184]
为了方便用户查看应用系统中各层级之间的调用关系，对调用关系作出实时监控，同时实时展示应用系统的故障点，本发明实施例还提供一种故障分析装置。同时，设计了可视化的界面，供用户操作和查看。
[0185]
故障分析装置的内部功能架构如图5所示，包括如下一项或多项：子系统调用链模块、服务调用链模块、调用明细模块、性能分析模块、配置字典模块、数据处理模块、告警信息模块、日志采集模块，自研分析算法模块。
[0186]
日志采集模块从各主机中部署的日志代理中获取日志，上传至kafka集群，在需要进行数据处理时，从kafka集群中获取各调用链日志。获取后的调用链日志交由数据处理模块处理。
[0187]
数据处理模块对各调用链日志进行分析，依据各调用链的调用链全局唯一标识traceid解析调用关系。具体为：通过调用链全局唯一标识traceid可以得到完整调用链信息，即将具有相同traceid的调用链日志集合，从中得到调用顺序。图6示出了一种可能的调用链关系图，从中分析得到本次涉及调用顺序依次为：(1)服务a发起调用服务b；(2)服务b同时发起调用服务c、服务d；(3)服务b发起调用服务e。
[0188]
图6中示出的是一种服务之间的调用关系示意图，这些服务由于具有相同的traceid而被表示在一个调用链中，每个服务都会具有的字段信息如表2所示。父节点调用号表示调用方，本次调用号表示服务自己的id号，也就是被调用方，例如在图6中，服务a的父节点调用号为-1，本次调用号为1，即表示服务-1调用了服务1(服务a的调用号)。本机ip信息表示该服务部署在哪个主机上。每个服务具有的字段信息不限于表2所示，还可包括具体的方法名、该服务所属的主机所属的子系统、应用系统、数据中心等。本发明实施例对此不作限制。
[0189]
表2
[0190][0191]
系统看板模块将各种结果提供可视化界面供用户查看。向用户展示了平台上当前监控的应用系统健康状况，含应用系统名，当前告警数量，同时包含颜色标注。如图7示出了一种可能的初始的应用状态看板。
[0192]
子系统调用链模块用于基于各调用链日志，以子系统为维度，生成子系统的调用关系图，并向用户展示子系统之间的调用关系图。子系统调用链生成：获取全部的节点数据，先按照主机名进行聚合，然后按照子系统名聚合，将调用汇总到子系统级别得到子系统的调用链。图8示出了一种可能的子系统调用链的显示界面。用户先点击左侧的子系统调用链，在弹出的页面中输入查询的业务系统、子系统、查询时间段后点击查询，那么在展示框中就会展示相应的有关该子系统的调用链。若用户没有选择任何子系统，则展示框中展示该应用系统的所有子系统的调用链。
[0193]
子系统的调用关系图中具有作为故障点的子系统的指示信息。例如调用链中将正常子系统与异常子系统分别以不同颜色、不同形状或其他指示信息等进行标注，点击某子系统图标，可在右侧展示其对应的主机列表，点击某主机，可以进一步下探到主机下的服务、方法名。
[0194]
可选地，在用户点击查询后，为了方便用户实时监控调用关系的变化，可以设置间隔一段时间后自动更新该调用关系图，例如每20s日志采集模块获取一次在这20s内产生的各调用链日志，数据处理模块进行处理后生成新的子系统调用链图。
[0195]
服务调用链模块用于向用户展示服务之间的调用关系图。原理同子系统调用链模块，在此不再赘述。图9示出了一种可能的服务调用链的显示界面。调用链中将正常服务与异常服务分别以不同颜色进行标注，点击某服务图标，可在右侧展示其对应的主机列表，点击某主机，可以进一步下探到主机下的服务、方法名。
[0196]
调用明细模块提供指定条件的明细数据查询。同时实时输出系统 数据中心 子系
统 主机 服务 方法粒度的成功率、tps、耗时数据等，图10示出了一种可能的调用明细的显示界面。
[0197]
告警信息模块用于根据告警规则，确定告警数据并进行存储。
[0198]
自研分析算法模块根据得到的告警信息，进行溯源分析，对整个应用系统从子系统、主机、服务、方法粒度进行溯源分析，最终得到应用系统的故障点信息进行展示。具体的故障分析方法在上文中有过详述。
[0199]
当用户在可视化界面中点击根因分析时，告警信息模块和自研分析算法模块启动，将故障分析结果展示给用户，图11示出了一种可能的根因分析的显示界面。
[0200]
图12示出了图5中所示的故障分析装置的内部功能架构的更加细化的功能架构图。
[0201]
基于相同的技术构思，图13示例性的示出了本发明实施例提供的一种应用系统的故障分析装置的结构，该结构可以执行应用系统的故障分析的流程。
[0202]
如图13所示，该装置具体包括：
[0203]
获取单元1301，用于获取应用系统在运行过程中产生的各调用链日志；
[0204]
确定单元1302，用于基于调用链监控项，确定各调用链日志是否满足告警规则；所述调用链监控项用于表征调用链日志中的被调用方信息；
[0205]
将满足告警规则的调用链日志中的调用链监控项作为告警数据；
[0206]
处理单元1303，用于按照所述调用链监控项所表征的各维度对各告警数据进行分析，确定所述应用系统的故障点；所述各维度包括主机维度、子系统维度、服务维度和方法维度中的至少一项。
[0207]
可选地，所述调用链监控项所表征的维度包括主机维度；
[0208]
所述处理单元1303，具体用于：
[0209]
针对各告警数据中的任一告警主机，确定在所述各告警数据中所述告警主机关联的告警服务的第一数量；根据所述告警主机上运行的所有服务的第二数量及所述第一数量，确定所述告警主机是否为所述应用系统的故障点。
[0210]
可选地，所述调用链监控项所表征的维度还包括服务维度；
[0211]
所述处理单元1303，具体用于：
[0212]
在所述第一数量与第二数量之间的第一预设关系大于第一预设阈值，则确定所述告警主机为所述应用系统的故障点；
[0213]
在所述第一预设关系不大于所述第一预设阈值，则确定所述告警主机的告警服务为所述应用系统的故障点。
[0214]
可选地，所述调用链监控项所表征的维度还包括子系统维度；
[0215]
所述处理单元1303，还用于：
[0216]
针对确定为故障点的各告警主机，确定各告警主机所属的各子系统；针对任一子系统，若属于所述子系统的告警主机的第三数量与属于所述子系统的全部主机的第四数量之间的第二预设关系满足第二预设阈值，则确定所述子系统为所述应用系统的故障点。
[0217]
可选地，所述调用链监控项所表征的维度包括服务维度；
[0218]
所述处理单元1303，具体用于：
[0219]
针对各告警数据中的任一告警服务，确定在所述各告警数据中所述告警服务关联
的告警主机的第五数量；确定所述第五数量与运行所述告警服务的所有主机的第六数量之间的第三预设关系；在所述第三预设关系大于第三预设阈值时，确定所述告警服务为所述应用系统的故障点。
[0220]
可选地，所述调用链监控项所表征的维度包括方法维度；
[0221]
所述处理单元1303，具体用于：
[0222]
针对各告警数据中的任一告警方法，基于同一告警主机中的第七数量和第八数量，确定所述告警方法是否为所述应用系统的故障点；所述第七数量用于表征告警主机中运行的所述告警方法所属服务下的各告警方法的数量；所述第八数量用于表征告警主机中运行的所述告警方法所属服务下的所有方法的数量。
[0223]
可选地，所述处理单元1303，具体用于：
[0224]
在所述第七数量与第八数量之间的第四预设关系大于第四预设阈值，且运行所述告警方法所属服务的告警主机的第九数量和运行所述告警方法所属服务的所有主机的第十数量之间的第五预设关系不大于第五预设阈值，则确定所述告警主机上运行的所述告警方法所属服务为所述应用系统的故障点。
[0225]
可选地，所述处理单元1303，具体用于：
[0226]
在所述第七数量与第八数量之间的第四预设关系大于第四预设阈值，且运行所述告警方法所属服务的告警主机的第九数量和运行所述告警方法所属服务的所有主机的第十数量之间的第五预设关系大于第五预设阈值，则确定运行的所述告警方法所属服务为所述应用系统的故障点。
[0227]
可选地，所述处理单元1303，具体用于：
[0228]
在所述第七数量与第八数量之间的第四预设关系不大于第四预设阈值，且运行所述告警方法的告警主机的第十一数量和运行所述告警方法的所有主机的第十二数量之间的第六预设关系大于第六预设阈值，则确定所述告警方法为所述应用系统的故障点。
[0229]
可选地，所述处理单元1303，具体用于：
[0230]
在所述第七数量与第八数量之间的第四预设关系不大于第四预设阈值，且运行所述告警方法的告警主机的第十一数量和运行所述告警方法所属服务的所有主机的第十二数量之间的第六预设关系不大于第六预设阈值，则确定所述告警主机上运行的所述告警方法为所述应用系统的故障点。
[0231]
可选地，所述处理单元1303，还用于：
[0232]
基于各调用链日志，以子系统为维度，生成子系统的调用关系图；所述子系统的调用关系图中具有作为故障点的子系统的指示信息；和/或，
[0233]
基于各调用链日志，以服务为维度，生成服务的调用关系图；所述服务的调用关系图中具有作为故障点的服务的指示信息。
[0234]
基于相同的技术构思，本技术实施例提供了一种计算机设备，如图14所示，包括至少一个处理器1401，以及与至少一个处理器连接的存储器1402，本技术实施例中不限定处理器1401与存储器1402之间的具体连接介质，图14中处理器1401和存储器1402之间通过总线连接为例。总线可以分为地址总线、数据总线、控制总线等。
[0235]
在本技术实施例中，存储器1402存储有可被至少一个处理器1401执行的指令，至少一个处理器1401通过执行存储器1402存储的指令，可以执行上述应用系统的故障分析方
法的步骤。
[0236]
其中，处理器1401是计算机设备的控制中心，可以利用各种接口和线路连接计算机设备的各个部分，通过运行或执行存储在存储器1402内的指令以及调用存储在存储器1402内的数据，从而进行应用系统的故障分析。可选的，处理器1401可包括一个或多个处理单元，处理器1401可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1401中。在一些实施例中，处理器1401和存储器1402可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。
[0237]
处理器1401可以是通用处理器，例如中央处理器(cpu)、数字信号处理器、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本技术实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
[0238]
存储器1402作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器1402可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(random access memory，ram)、静态随机访问存储器(static random access memory，sram)、可编程只读存储器(programmable read only memory，prom)、只读存储器(read only memory，rom)、带电可擦除可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、磁性存储器、磁盘、光盘等等。存储器1402是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本技术实施例中的存储器1402还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。
[0239]
基于相同的技术构思，本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质存储有计算机可执行程序，计算机可执行程序用于使计算机执行上述任一方式所列的应用系统的故障分析的方法。
[0240]
本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0241]
本技术是参照根据本技术的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0242]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特
定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0243]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0244]
显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的精神和范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包含这些改动和变型在内。