业务故障根因定位方法、装置、电子设备及存储介质与流程

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.图1是本发明提供的业务故障根因定位方法的流程示意图；
34.图2是本发明提供的业务故障根因定位方法中调用链的示意图；
35.图3是本发明提供的业务故障根因定位方法中最大生成树的生成过程示意图；
36.图4是本发明提供的业务故障根因定位方法中告警时间的示意图之一；
37.图5是本发明提供的业务故障根因定位方法中告警时间的示意图之二；
38.图6是本发明提供的业务故障根因定位装置的结构示意图；
39.图7是本发明提供的电子设备的结构示意图。
具体实施方式
40.为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
41.下面结合图1-图6描述本发明的业务故障根因定位方法、装置、电子设备及存储介质。
42.图1是本发明提供的业务故障根因定位方法的流程示意图。下面结合图1描述本技术实施例提供的业务故障根因定位方法。如图1所示，该方法包括：步骤101、将确定目标业务的目标指标存在异常的时刻，确定为异常时刻。
43.具体地，本发明实施例提供的业务故障根因定位方法的执行主体为本发明提供的业务故障根因定位装置。
44.目标业务，可以是业务系统承载的某一项业务。
45.对于目标业务，可以检测该业务的目标指标，判断该业务的目标指标是否正常。
46.示例性地，可以周期性的检测目标业务的目标指标，判断本周期内目标业务的目标指标是否正常。
47.示例性地，可以检测第二目标时间段内该业务的目标指标，判断第二目标时间段内该业务的目标指标是否正常。
48.第二目标时间段的时长可以根据实际情况设定，对于第二目标时间段的具体时长，本发明实施例不进行具体限定。
49.目标指标，是用于表征业务是否正常的指标。示例性地，目标指标可以包括平均延时或成功率等。对于具体的目标指标，本发明实施例不进行具体限定。目标指标可以俗称为“黄金指标”。
50.在目标业务第二目标时间段内的目标指标落入正常范围的情况下，可以确定目标业务的目标指标正常，不存在异常；在目标业务第二目标时间段内的目标指标未落入正常范围的情况下，可以确定目标业务的目标指标异常。
51.确定目标业务的目标指标异常之后，可以将确定目标业务的目标指标存在异常的时刻，作为目标业务的异常时刻。
52.步骤102、基于以异常时刻为结束时刻的目标时间段内目标业务的调用链的信息，
确实调用链上的各根因节点。
53.具体地，调用链技术是较为常用的一种运行业务的方法，将一系列服务节点按照一定顺序作为一个调用链提供给用户，以向用户提供各种业务。
54.如图2所示，每一条调用链由多个服务节点(简称“节点”)构成，一条完整的调用链基本呈现链路单向传播的关系，每一条调用链都存在着唯一标识traceid与其它调用链进行区分。根据调用链的调用逻辑，可以获知调用耗时与是否调用成功。调用耗时与是否调用成功，能够反映节点故障信息。
55.调用链的信息，是指在业务系统完成一次业务调用的过程中，将服务节点之间的调用信息(时间、接口、层次、结果)打点到日志中，然后将所有的打点数据连接为一个树状链条，即产生一条调用链数据。
56.目标业务的调用链可以有一条或多条。
57.本发明实施例中获取目标时间段(该目标时间段为第一目标时间段)内目标业务的调用链的信息。第一目标时间段的时长是预设的，第一目标时间段的结束时刻为通过步骤101所确定的异常时刻。
58.第一目标时间段的时长可以根据实际情况设定，对于第一目标时间段的具体时长，本发明实施例不进行具体限定。
59.可选地，第一目标时间段的时长为5分钟。
60.在一条调用链上，若底层节点耗时较多或调用失败，则上层节点的耗时也会相对应增加或失败，调用链的根因传递是自底向上的，那么越是底层的节点越有可能成为根因节点。因此，可以基于各调用链上各节点的调用耗时进行分析，确定各根因节点。
61.步骤103、基于各根因节点对应的告警，以及各设备之间的拓扑关系，确定各根因节点对应的告警中的根因告警。
62.具体地，基于步骤102已定位到的某异常时刻下的各根因节点，关联业务系统的平台架构的拓扑关系，进一步定位各根因节点对应的告警，对各根因节点对应的告警之间的关系进行分析，最终定位到根因告警。
63.根因节点对应的告警，指与根因节点关联的告警。
64.本发明实施例通过将确定目标业务的目标指标存在异常的时刻，确定为异常时刻，基于以异常时刻为结束时刻的目标时间段内目标业务的调用链的信息，确实调用链上的各根因节点，基于各根因节点对应的告警，以及各设备之间的拓扑关系，确定各根因节点对应的告警中的根因告警，能实现快速、准确的根因定位。进一步地，业务根因定位场景的应用架构环环相扣，具有明显的层次布局，通过对业务场景解耦分析，可以得到三个更加细致的独立场景，有助于明确各场景实际业务，并且降低各场景算法的复杂度，根因定位更快速、准确，避免了传统方法未在根因定位的逻辑进行分层解耦，难以实现快速定位的不足，能够实现对业务系统的有效监控，将运营管理与运维保障进行融合，并能基于物理网元结构进行定位。
65.基于上述任一实施例的内容，目标指标包括：平均延时和成功率。
66.具体地，目标指标可以包括平均延时和成功率，结合平均延时和成功率，确定目标业务是否异常。
67.可以通过绝对阈值检测法检测平均延时和成功率是否异常。判断是否异常的具体
逻辑如下：
68.a.若平均延时》＝平均延时阈值且成功率》＝成功率阈值，则返回耗时异常的故障类型；
69.b.若平均延时《平均延时阈值且0《成功率《成功率阈值，则返回成功率异常的故障类型；
70.c.若平均延时《平均延时阈值且成功率＝＝0，则返回数据库异常的故障类型；
71.d.若平均延时》＝平均延时阈值且0《成功率《成功率阈值，则返回耗时和成功率同时异常的故障类型；
72.e.若平均延时》＝平均延时阈值且成功率＝＝0，则返回耗时和数据库同时异常的故障类型。
73.平均延时阈值avgtimethreshold可以根据实际情况设定，例如平均延时阈值为1s。对于平均延时阈值的具体值，本发明实施例不进行具体限定。
74.成功率阈值successrate可以根据实际情况设定，例如成功率阈值为0.9。对于成功率阈值的具体值，本发明实施例不进行具体限定。
75.本发明实施例不同于复杂的异常检测算法，而是采用简单的绝对阈值与分类的思想对业务的目标指标进行分析，方法快速有效，且易于调整，并且细致的分类能够反映不同情况下的真实业务问题。
76.基于上述任一实施例的内容，基于以异常时刻为结束时刻的目标时间段内目标业务的调用链的信息，确实调用链上的各根因节点，具体包括：基于目标时间段内目标业务的调用链的信息，确定调用链上的各异常节点。
77.具体地，对于每一条调用链，基于该调用链的耗时确定该调用链是否为调用耗时异常的调用链。
78.调用链的耗时的统计是以正态分布，可以采用预设的分位数来近似置信区间，即可筛选出调用耗时异常的调用链。
79.优选地，预设的分位数可以为95分位数，采用95分位数来近似置信区间为5％的数据区间。若调用链的耗时属于上述5％的数据区间，则该调用链为异常调用链。
80.可选地，预设的分位数还可以为90分位数，采用90分位数来近似置信区间为10％的数据区间。若调用链的耗时属于上述10％的数据区间，则该调用链为异常调用链。
81.可以通过搜索的方式遍历各调用耗时异常的调用链上的节点，以确定各异常节点。
82.调用链上同类型的节点的调用耗时都是基于正态统计分布。
83.若节点耗时满足该类型节点的异常阈值或者该节点调用失败，该节点则为异常节点；若节点耗时不满足该类型节点的异常阈值或者该节点调用成功，但该节点的父节点耗时是该节点所有同层节点的耗时总和的两倍以上，那么该节点是疑似异常节点。
84.以图2中的部分调用链为例，调用链异常节点的搜索过程余下：
85.从头节点开始记osb_001为异常节点，那么记录节点信息{
‘
osb_001’:[1,1，0],}(节点名:[异常次数，深度，是否疑似异常(异常0，疑似异常1，正常2)])；
[0086]
继续下探搜索到csf_001节点；
[0087]
csf_001节点耗时满足csf_001的异常阈值，那么记录节点信息{
‘
osb_001’:[1,1，
0],
‘
csf_001’：[1,2，0]，}；
[0088]
已知csf_001为异常节点，则继续下探搜索到csf_003节点；
[0089]
csf_003节点耗时不满足csf_003的异常阈值但为调用失败的节点,那么记录节点信息{
‘
osb_001’:[1,1，0],
‘
csf_001’：[1,2，0]，
[0090]
‘
csf_003’：[1,3，0]，}；
[0091]
已知csf_003为异常节点，则继续下探搜索到local_15,local_16节点；
[0092]
local_15节点耗时不满足local_15的异常阈值但为调用失败的节点,那么记录节点信息{
‘
osb_001’:[1,1，0],
‘
csf_001’：[1,2，0]，
‘
csf_003’：[1,3，0]，’local_15’:[1,4，0]}；
[0093]
local_16节点耗时不满足local_16的异常阈值且调用成功，那么local_16不属于异常节点；分析csf_003的耗时为20s而csf_003子节点的耗时分别为自调用、local_15、local_16(4s、3s、2s),超过子节点调用耗时的一倍以上，那么local_16为疑似异常节点，那么记录节点信息{
‘
osb_001’:[1,1，0],
‘
csf_001’：[1,2，0]，
‘
csf_003’：[1,3，0]，’local_15’:[1,4，0]’local_16’:[1,4，1]}；
[0094]
已知local_15为异常节点，则继续下探搜索到jdbc层的db_003节点；
[0095]
db_003节点耗时不满足db_003的异常阈值且调用成功，那么local_16不属于异常节点；分析local_15的耗时为3s而local_15子节点的耗时为db_003 1s,超过子节点调用耗时的一倍以上，那么db_003为疑似异常节点，那么记录节点信息{
‘
osb_001’:[1,1，0],
‘
csf_001’：[1,2，0]，
‘
csf_003’：[1,3，0]，’local_15’:[1,4，0]’local_16’:[1,4，1]，’db_003’:[1,5，1]}；
[0096]
已知local_16为疑似异常节点，则停止搜索；
[0097]
当需要进行全局搜索时，已知local_16为疑似异常节点且存在子节点；
[0098]
不断继续下搜，后续子节点的判断皆采取调用状态判断而忽略延时的影响。例如db_003节点，在local_16调用下并不会作为异常记录，那么记录db_003节点信息{
‘
osb_001’:[1,1，0],
‘
csf_001’：[1,2，0]，
‘
csf_003’：[1,3，0]，’local_15’:[1,4，0]’local_16’:[1,4，1]，’db_003’:[1,5，1]}仍与local_15调用下的记录信息一致，重复此过程完成全部搜索。
[0099]
通过上述过程，可以确定各异常节点。
[0100]
基于各异常节点的信息，确定各异常节点中的各根因节点。
[0101]
可选地，底层节点耗时较多或调用失败，则上层节点的耗时也会相对应增加或失败，可以通过分析异常节点耗时较多或调用失败是自身原因导致的还是该异常节点的后代节点的原因导致的，确定异常节点中的根因节点。
[0102]
若异常节点耗时较多或调用失败是自身原因导致的，则可以将该异常节点确定为根因节点；若异常节点耗时较多或调用失败是该异常节点的后代节点的原因导致的，则不将该异常节点确定为根因节点。
[0103]
本发明实施例不同于对异常事件数据生成异常id并存储异常事件与请求id映射关系的方法，而是有效利用了节点信息继承的条件，逐子节点分析节点的异常状态，再通过故障次数与故障率确定根因，并采取剪枝策略加快搜索速度，从而能够更快速且准确地定位根因节点。进一步地，避免了传统方法故障传播路径需要事后梳理，难以快速进行拓扑架
构优化的不足。
[0104]
基于上述任一实施例的内容，基于各异常节点的信息，确定各异常节点中的各根因节点，具体包括：基于每一异常节点在调用链中的深度和故障率，确定各异常节点中的各可能根因节点。
[0105]
可选地，已知统计的调用链数为n
调用链
，某层(层的深度为deep)某节点的总调用次数为n
节点
，而故障次数为m
故障
，疑似故障次数为l
疑似
。可以从最深层的异常节点开始分析。
[0106]
若m
故障
》＝0.8*(deep-2)*0.05*n
调用链
且节点故障率p
故障率
大于故障率阈值，则该节点则为可能根因节点。
[0107]
或者，若m
故障
》＝0.8*(deep-2)*0.1*n
调用链
且节点故障率p
故障率
大于故障率阈值，则该节点则为可能根因节点。
[0108]
p
故障率
＝m
故障
/n
节点
[0109]
故障率阈值可以根据实际情况设定。对于故障率阈值的具体值，本发明实施例不进行具体限定。
[0110]
优选地，故障率阈值默认0.5。
[0111]
基于每一可能根因节点的子节点的信息，确定各异常节点中的各根因节点。
[0112]
可选地，若某层存在单个可能根因节点，则直接作为根因节点。若某层下存在多个可能根因节点，返回故障次数较多的可能根因节点作为根因节点；若某层下存在多个可能根因节点且故障次数相同，则返回故障率较高的可能根因节点作为根因节点；若故障次数与故障率相等，则返回docker节点作为根因节点。
[0113]
需要说明的是，若存在某服务应用调用链拓扑地图，其中x服务调用a、b、c、d四个应用节点，而在实际搜索过程中，x服务只调用了a、b、c三种应用节点，那么返回d节点为遗失节点。
[0114]
根据调用链搜索统计得到的节点信息，整合业务节点与服务器节点的拓扑关系，最终得到以下服务器节点的异常统计节点信息({深度：{2:{
‘
调用节点’:总调用节点数},1:{
‘
疑似异常节点’:疑似异常节点数},0:{
‘
异常节点’:异常节点数}}})。
[0115]
例如，实际搜索调用链数为102次，从最深的第五层开始分析，第五层存在default(表示不存在该节点)与docker_006故障次数满足108*0.1*0.8*3且故障率大于故障率阈值，基于最深层节点最有可能作为根因的原则，停止分析并直接定位到第五层的docker_006节点。(可以看到其余层级的数据尽管满足故障次数，但并不满足故障率，某种程度上可以作为验证，说明真正的根因节点正是docker_006节点)。
[0116]
本发明实施例通过确定各异常节点中的各可能根因节点，基于每一可能根因节点的子节点的信息，确定各根因节点，能够更快速且准确地定位根因节点。
[0117]
基于上述任一实施例的内容，基于各根因节点对应的告警，以及各设备之间的拓扑关系，确定各根因节点对应的告警中的根因告警，具体包括：基于预设的关联规则，确定各目标告警对及每一目标告警对包括的两条根因节点对应的告警之间的关联关系得分。
[0118]
可选地，基于预设的关联规则，确定各根因节点对应的告警中频繁发生的告警对。每一告警对包括两条告警。
[0119]
设备指根因节点所在的设备。
[0120]
基于预设的关联规则，还可以确定每一告警对包括的两条告警之间的关联关系得
分。
[0121]
关联规则，可以是根据历史告警数据的和实时的告警数据流获得的。
[0122]
需要说明的是，可以根据历史告警数据的和实时的告警数据流不断去更新主次规则表(即预设的关联规则)，去挖掘告警之间新的规则并剔除错误的关联规则，提高目标告警对确定和关联关系得分获取的准确性，从而能更快速且准确地定位根因告警。
[0123]
基于各目标告警对及每一目标告警对包括的两条根因节点对应的告警的关联关系得分，确定各根因节点对应的告警中的根因告警。
[0124]
可选地，基于各告警对包括的两条告警之间的关联关系得分，可以确定各根因节点对应的告警之间的主次关系，从而可以将其中相对主要的告警确定为根因告警。
[0125]
本发明实施例基于预设的关联规则，确定各目标告警对及每一目标告警对包括的两条根因节点对应的告警之间的关联关系得分，基于各目标告警对及每一目标告警对包括的两条根因节点对应的告警的关联关系得分，确定各根因节点对应的告警中的根因告警，能够更快速且准确地定位根因告警。
[0126]
基于上述任一实施例的内容，基于各目标告警对及每一目标告警对包括的两条根因节点对应的告警之间的关联关系得分，确定各根因节点对应的告警中的根因告警，具体包括：基于各目标告警对及每一目标告警对包括的两条根因节点对应的告警之间的关联关系得分，生成无向图。
[0127]
具体地，无向图中的顶点表示根因节点对应的告警，无向图中的边表示该条边所连接的两个顶点所表示的告警构成目标告警对，边的权值为告警之间的关联关系得分，从而可以生成无向图。本发明实施例中的无向图可以称为告警图。
[0128]
基于无向图的最大生成树，确定各根因节点对应的告警中的根因告警。
[0129]
具体地，最大生成树算法与最小生成树相似，目的是对于给定一个无向图g(v,e)里，每一个(u,v)被赋予了一个权值w，在无向图中选取一个边集合e的一个子集e'，使得点集合v中所有点被e'中的边所连接，并且使集合e'中所有边权值之和最大。
[0130]
具体可以采用kruskal’s algorithm(kruskal算法)或者prim’salgorithm(prim算法)。上述两种算法都应用了greedy的思想。以kruskal's algorithm为例，每次挑选一个权值最大的边(u,v)，判断它与e'中的边是否构成一个环；如果不构成环，则将(u,v)加入到e'中；否则，删除边(u,v)；重复此步骤，直到图中所有点被树所连接。顶点1-6构成的无向图的最大生成树的具体实现过程如图3所示。
[0131]
获取无向图的最大生成树之后，可以将入度为0的顶点所表示的告警确定为根因告警。
[0132]
本发明实施例基于各目标告警对及每一目标告警对包括的两条根因节点对应的告警之间的关联关系得分，生成无向图，基于无向图的最大生成树，确定各根因节点对应的告警中的根因告警，能够更快速且准确地定位根因告警。
[0133]
基于上述任一实施例的内容，基于各目标告警对及每一目标告警对包括的两条根因节点对应的告警之间的关联关系得分，生成无向图，具体包括：基于各根因节点对应的告警的告警时间，将各根因节点对应的告警划分为若干个目标事件。
[0134]
具体地，可以基于各根因节点对应的告警的告警时间，得出相同告警的高频时间与不同告警之间的关联时间。
[0135]
相同告警的高频时间，指判断某告警二次或多次告警的平均间隔。高频时间，用于在事件聚合过程中聚合发生时间相近的相同告警。
[0136]
通过考虑不同设备以及不同时间段，进行高频时间的加权处理。
[0137]
高频时间的计算方法如下：
[0138]
首先在不同设备上根据告警开始时间和结束时间进行高频时间的初步计算，即对重叠时间区间进行合并；然后将告警的首次发生时间与最后发生时间进行作差；最后根据告警被划分到重叠区间的不同次数以及不同设备上的信息进行加权处理。
[0139]
以图4所示的告警a的时间段为例，设备a1上的高频时间为：st3-st1，st5-st4，高频时间段为2个；设备a2上的高频时间为：st4-st3，高频时间段为1个。
[0140]
告警a的高频时间的计算公式为：
[0141][0142]
其中，5/5和2/4分别表示设备a1和设备a2的权重。
[0143]
不同告警之间的关联时间，指判断某告警与其它告警的关联时长。关联时间，用于在事件聚合过程中聚合发生时间相近的两个不同告警。
[0144]
通过考虑不同设备以及不同时间段，进行关联时间的加权处理。
[0145]
关联时间的计算方法如下：
[0146]
首先在不同设备上根据开始时间和结束时间进行关联时间的初步计算，即对重叠的次告警时间区间进行合并；然后将次告警的发生时间和前向最近主告警的发生时间进行作差；最后根据告警被划分到主告警区间内的不同次数以及不同设备上的信息进行加权处理。
[0147]
以图5所示的告警为例，设备a1上和告警b关联的两次告警为b1和b2，关联时间为st1b-st4，st3b-st5，关联次数为2次。对所有设备上的关联告警事件进行加权平均，结果会倾向于频发发生a告警的设备。
[0148]
根据各设备之间的拓扑关系、相同告警的高频时间与不同告警之间的关联时间，可以将具有关联性的多条告警划分至同一目标事件中，确定若干个目标事件。
[0149]
需要说明的是，还可以通过历史数据进行不断学习高频时间和关联时间的计算方法，在不断迭代的过程中使得事件划分准确度提高。
[0150]
分别对于每一目标事件，生成无向图。
[0151]
具体地，分别对于每一目标事件，基于该目标事件包括的目标告警对及每一目标告警对包括的两条根因节点对应的告警之间的关联关系得分，生成该目标事件对应的无向图。
[0152]
生成无向图的过程可以参见前述实施例，此处不再赘述。
[0153]
本发明实施例基于各根因节点对应的告警的告警时间，将各根因节点对应的告警划分为若干个目标事件，能针对每一目标事件更快速且准确地定位根因告警。
[0154]
下面对本发明提供的业务故障根因定位装置进行描述，下文描述的业务故障根因定位装置与上文描述的业务故障根因定位方法可相互对应参照。
[0155]
图6是本发明提供的业务故障根因定位装置的结构示意图。基于上述任一实施例
的内容，如图6所示，业务故障根因定位装置包括指标检测模块601、节点定位模块602和告警定位模块603，其中：
[0156]
指标检测模块601，用于将确定目标业务的目标指标存在异常的时刻，确定为异常时刻；
[0157]
节点定位模块602，用于基于以异常时刻为结束时刻的目标时间段内目标业务的调用链的信息，确实调用链上的各根因节点；
[0158]
告警定位模块603，用于基于各根因节点对应的告警，以及各设备之间的拓扑关系，确定各根因节点对应的告警中的根因告警。
[0159]
具体地，指标检测模块601、节点定位模块602和告警定位模块603顺次电连接。
[0160]
对于目标业务，指标检测模块601可以检测第二目标时间段内该业务的目标指标，判断第二目标时间段内该业务的目标指标是否正常。
[0161]
在目标业务第二目标时间段内的目标指标落入正常范围的情况下，指标检测模块601可以确定目标业务的目标指标正常，不存在异常；在目标业务第二目标时间段内的目标指标未落入正常范围的情况下，指标检测模块601可以确定目标业务的目标指标异常。
[0162]
节点定位模块602获取目标时间段内目标业务的调用链的信息，基于各调用链上各节点的调用耗时进行分析，确定各根因节点。
[0163]
告警定位模块603基于已定位到的某异常时刻下的各根因节点，关联业务系统的平台架构的拓扑关系，进一步定位各根因节点对应的告警，对各根因节点对应的告警之间的关系进行分析，最终定位到根因告警。
[0164]
可选地，目标指标包括：平均延时和成功率。
[0165]
可选地，节点定位模块602可以包括：
[0166]
异常节点确定单元，用于基于目标时间段内目标业务的调用链的信息，确定调用链上的各异常节点；
[0167]
根因节点确定单元，用于基于各异常节点的信息，确定各异常节点中的各根因节点。
[0168]
可选地，告警定位模块603可以包括：
[0169]
关联单元，用于基于预设的关联规则，确定各目标告警对及每一目标告警对包括的两条根因节点对应的告警之间的关联关系得分；
[0170]
定位单元，用于基于各目标告警对及每一目标告警对包括的两条根因节点对应的告警的关联关系得分，确定各根因节点对应的告警中的根因告警。
[0171]
可选地，根因节点确定单元可以包括：
[0172]
可能根因确定子单元，用于基于每一异常节点在调用链中的深度和故障率，确定各异常节点中的各可能根因节点；
[0173]
根因节点确定子单元，用于基于每一可能根因节点的子节点的信息，确定各异常节点中的各根因节点。
[0174]
可选地，定位单元可以包括：
[0175]
图生成子单元，用于基于各目标告警对及每一目标告警对包括的两条根因节点对应的告警之间的关联关系得分，生成无向图；
[0176]
告警定位子单元，用于基于无向图的最大生成树，确定各根因节点对应的告警中
的根因告警。
[0177]
可选地，图生成子单元，具体用于基于各根因节点对应的告警的告警时间，将各根因节点对应的告警划分为若干个目标事件；分别对于每一目标事件，生成无向图。
[0178]
本发明实施例提供的业务故障根因定位装置，用于执行本发明上述业务故障根因定位方法，其实施方式与本发明提供的业务故障根因定位方法的实施方式一致，且可以达到相同的有益效果，此处不再赘述。
[0179]
该业务故障根因定位装置用于前述各实施例的业务故障根因定位方法。因此，在前述各实施例中的业务故障根因定位方法中的描述和定义，可以用于本发明实施例中各执行模块的理解。
[0180]
本发明实施例通过将确定目标业务的目标指标存在异常的时刻，确定为异常时刻，基于以异常时刻为结束时刻的目标时间段内目标业务的调用链的信息，确实调用链上的各根因节点，基于各根因节点对应的告警，以及各设备之间的拓扑关系，确定各根因节点对应的告警中的根因告警，能实现快速、准确的根因定位。进一步地，业务根因定位场景的应用架构环环相扣，具有明显的层次布局，通过对业务场景解耦分析，可以得到三个更加细致的独立场景，有助于明确各场景实际业务，并且降低各场景算法的复杂度，根因定位更快速、准确，避免了传统方法未在根因定位的逻辑进行分层解耦，难以实现快速定位的不足，能够实现对业务系统的有效监控，将运营管理与运维保障进行融合，并能基于物理网元结构进行定位。
[0181]
下面对本发明提供的电子设备及存储介质进行描述，下文描述的电子设备及存储介质与上文描述的业务故障根因定位方法可相互对应参照。
[0182]
图7示例了一种电子设备的实体结构示意图，如图7所示，该电子设备可以包括：处理器(processor)710、通信接口(communication interface)720、存储器(memory)730和通信总线740，其中，处理器710，通信接口720，存储器730通过通信总线740完成相互间的通信。处理器710可以调用存储器730中的计算机程序，以执行业务故障根因定位方法的步骤，例如包括：将确定目标业务的目标指标存在异常的时刻，确定为异常时刻；基于以异常时刻为结束时刻的目标时间段内目标业务的调用链的信息，确实调用链上的各根因节点；基于各根因节点对应的告警，以及各设备之间的拓扑关系，确定各根因节点对应的告警中的根因告警。
[0183]
此外，上述的存储器730中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。
[0184]
另一方面，本发明还提供一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法所提供的业务故障根因定位方法的步
骤，例如包括：将确定目标业务的目标指标存在异常的时刻，确定为异常时刻；基于以异常时刻为结束时刻的目标时间段内目标业务的调用链的信息，确实调用链上的各根因节点；基于各根因节点对应的告警，以及各设备之间的拓扑关系，确定各根因节点对应的告警中的根因告警。
[0185]
另一方面，本技术实施例还提供一种处理器可读存储介质，所述处理器可读存储介质存储有计算机程序，所述计算机程序用于使所述处理器执行上述各实施例提供的方法的步骤，例如包括：将确定目标业务的目标指标存在异常的时刻，确定为异常时刻；基于以异常时刻为结束时刻的目标时间段内目标业务的调用链的信息，确实调用链上的各根因节点；基于各根因节点对应的告警，以及各设备之间的拓扑关系，确定各根因节点对应的告警中的根因告警。
[0186]
所述处理器可读存储介质可以是处理器能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(mo)等)、光学存储器(例如cd、dvd、bd、hvd等)、以及半导体存储器(例如rom、eprom、eeprom、非易失性存储器(nand flash)、固态硬盘(ssd))等。
[0187]
以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
[0188]
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。
[0189]
最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。