CN117194092A - 根因定位方法、根因定位装置、计算机设备及存储介质 - Google Patents
根因定位方法、根因定位装置、计算机设备及存储介质 Download PDFInfo
- Publication number
- CN117194092A CN117194092A CN202311213288.6A CN202311213288A CN117194092A CN 117194092 A CN117194092 A CN 117194092A CN 202311213288 A CN202311213288 A CN 202311213288A CN 117194092 A CN117194092 A CN 117194092A
- Authority
- CN
- China
- Prior art keywords
- service
- root cause
- service node
- node
- maintenance system
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 64
- 238000003860 storage Methods 0.000 title claims abstract description 21
- 238000012423 maintenance Methods 0.000 claims abstract description 264
- 238000011156 evaluation Methods 0.000 claims abstract description 143
- 230000005856 abnormality Effects 0.000 claims abstract description 39
- 230000001960 triggered effect Effects 0.000 claims abstract description 12
- 230000002159 abnormal effect Effects 0.000 claims description 56
- 230000006870 function Effects 0.000 claims description 40
- 230000008859 change Effects 0.000 claims description 37
- 230000004044 response Effects 0.000 claims description 16
- 230000004807 localization Effects 0.000 claims description 5
- 238000012216 screening Methods 0.000 claims description 4
- 238000004590 computer program Methods 0.000 description 20
- 238000012545 processing Methods 0.000 description 18
- 230000036541 health Effects 0.000 description 16
- 238000010586 diagram Methods 0.000 description 14
- 230000008569 process Effects 0.000 description 9
- 238000012544 monitoring process Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 4
- 239000000463 material Substances 0.000 description 3
- 230000008439 repair process Effects 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 2
- 238000012512 characterization method Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000010801 machine learning Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000026676 system process Effects 0.000 description 2
- 238000012549 training Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013527 convolutional neural network Methods 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 229910021389 graphene Inorganic materials 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 230000007480 spreading Effects 0.000 description 1
- 238000003892 spreading Methods 0.000 description 1
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本申请涉及一种根因定位方法、根因定位装置、计算机设备及存储介质。该方法包括：响应运维***触发根因定位指令，确定在当前时间窗口内运维***响应的多个服务节点；其中，在各服务节点中分别包括有至少一个服务请求，运维***用于执行至少一个服务请求，以实现服务节点对应的服务功能；获取运维***在分别执行各服务节点的服务请求时，对应产生的运维数据；基于运维数据，分别对各服务节点进行根因评价，得到针对各服务节点的评价结果；根因评价用于评价由服务节点导致运维***出现***异常的可能性程度；基于评价结果，从多个服务节点中确定出根因节点。采用本方法能够有效提高对故障***进行根因定位的效率和准确性。
Description
技术领域
本申请涉及计算机技术领域，特别是涉及一种根因定位方法、根因定位装置、计算机设备及计算机可读存储介质。
背景技术
随着科技的发展和计算机技术的广泛应用，越来越多复杂的软件***采用模块化方法，即将大型的服务应用分解为成百上千个更小，更独立，更易于管理的服务节点来执行。其中，服务节点间通过轻量级通信机制使得这些组件协同配合，从而形成一种高内聚低耦合的***架构。然而，由于服务节点之间存在复杂的依赖关系，服务节点可能沿着服务调用链传播，从而由少量的根因节点影响到关联节点，并最终导致业务级别的可用性问题。因此，当监控到***存在异常时，运维人员需要快速且准确的定位到故障的根因服务节点，防止故障的进一步传播。
在当前的定位根因节点的方法中，主要是基于专家经验和人工排查的方式进行，但这些方法往往依赖于人工经验对***的深入了解以及需要大量的运维数据来人工分析，从而限制了其在复杂***中的应用，导致根因定位的效率不高和准确性难以保证。
发明内容
基于此，有必要针对上述技术问题，提供一种能够提高根因定位效率和准确性的根因定位方法、根因定位装置、计算机设备、计算机可读存储介质和计算机程序产品。
第一方面，本申请提供了一种根因定位方法。所述方法包括：
响应运维***触发根因定位指令，确定在当前时间窗口内所述运维***响应的多个服务节点；其中，在各所述服务节点中分别包括有至少一个服务请求，所述运维***用于执行所述至少一个服务请求，以实现所述服务节点对应的服务功能；
获取所述运维***在分别执行各所述服务节点的服务请求时，对应产生的运维数据；
基于所述运维数据，分别对各所述服务节点进行根因评价，得到针对各所述服务节点的评价结果；所述根因评价用于评价由所述服务节点导致所述运维***出现***异常的可能性程度；
基于所述评价结果，从所述多个服务节点中确定出根因节点；
其中，所述根因节点为导致所述运维***出现***异常，以触发所述根因定位指令的异常服务节点。
在其中一个实施例中，所述基于所述运维数据，分别对各所述服务节点进行根因评价，得到针对各所述服务节点的评价结果，包括：
基于所述运维数据，确定所述运维***在分别响应各所述服务节点时的性能指标和功能指标；所述性能指标用于表征所述运维***在响应服务节点时的***性能状况，所述功能指标用于表征所述运维***在响应服务节点时所应用的功能服务状况；
基于预设的分数因子，对各所述服务节点的性能指标进行第一评分，得到针对所述性能指标的第一评价分数；以及
基于预设的权重因子，对各所述服务节点的功能指标进行第二评分，得到针对所述功能指标的第二评价分数；
基于所述第一评价分数和所述第二评价分数，确定针对各所述服务节点的评价结果。
在其中一个实施例中，所述性能指标表征有对应的指标值；
在确定所述运维***在分别响应各所述服务节点时的性能指标之后，还包括：
获取所述运维***在历史时间窗口内响应的历史服务节点的历史性能指标的历史指标值；所述历史时间窗口包括所述当前时间窗口；
将所述历史性能指标的历史指标值输入预训练的指标预测模型中进行安全性能预测，得到预测的安全性能区间；
基于所述当前时间窗口内的各所述服务节点的性能指标的指标值与所述安全性能区间之间的大小关系，确定各所述服务节点的性能指标的实时状态。
在其中一个实施例中，所述基于所述当前时间窗口内的各所述服务节点的性能指标的指标值与所述安全性能区间之间的大小关系，确定各所述服务节点的性能指标的实时状态，包括以下两项：
在预设时间长度内，若所述服务节点的性能指标的指标值均处于所述安全性能区间内，则确定所述服务节点的性能指标在所述预设时间长度内的实时状态为正常状态；
在预设时间长度内，若所述服务节点的性能指标的指标值均未处于所述安全性能区间内，则确定所述服务节点的性能指标在所述预设时间长度内的实时状态为异常状态。
在其中一个实施例中，所述基于预设的分数因子，对各所述服务节点的性能指标进行第一评分，得到针对所述性能指标的第一评价分数，包括：
将对应所述实时状态的性能指标的分数因子作为针对所述性能指标的第一评价分数；
其中，不同所述实时状态的性能指标对应预设有不同的分数因子。
在其中一个实施例中，所述功能指标表征有对应的指标值；
所述基于预设的权重因子，对各所述服务节点的功能指标进行第二评分，得到针对所述功能指标的第二评价分数，包括：
将所述功能指标的指标值与对应权重因子之间的乘积值作为针对所述性能指标的第一评价分数；
其中，不同的所述功能指标对应预设有不同的权重因子。
在其中一个实施例中，所述性能指标至少包括所述运维***在响应服务节点时的P99耗时、日志错误率、请求失败率和数据故障率；所述功能指标至少包括所述运维***在响应服务节点时的应用人数比例、异常应用比例、对应产生变更类型的运维数据的数量；
所述基于所述第一评价分数和所述第二评价分数，确定针对各所述服务节点的评价结果，包括：
针对每一所述服务节点，确定各个性能指标的第一评价分数和将各个功能指标的第二评价分数之间的总分数，并将所述总分数作为所述服务节点的评价结果。
在其中一个实施例中，所述基于所述评价结果，从所述多个服务节点中确定出根因节点，包括：
在各个所述服务节点，将对应所述总分数最高的目标服务节点作为根因节点。
在其中一个实施例中，所述响应所述运维***触发根因定位指令，包括：
获取终端用户发起的故障告警；
响应于在当前滑动时间窗内，所述故障告警的数量大于预设数量，自动触发根因定位指令。
第二方面，本申请还提供了一种根因定位装置。所述装置包括：
指令触发单元，被配置为执行响应运维***触发根因定位指令，确定在当前时间窗口内所述运维***响应的多个服务节点；其中，在各所述服务节点中分别包括有至少一个服务请求，所述运维***用于执行所述至少一个服务请求，以实现所述服务节点对应的服务功能；
路径参考单元，被配置为执行基于所述对话语句和所述账户信息，从预设路径库所存储的多个候选处理路径中确定出参考处理路径；所述候选处理路径为将多个任务节点按照预设顺序进行连接的工作流程；
数据获取单元，被配置为执行获取所述运维***在分别执行各所述服务节点的服务请求时，对应产生的运维数据；
节点评价单元，被配置为执行基于所述运维数据，分别对各所述服务节点进行根因评价，得到针对各所述服务节点的评价结果；所述根因评价用于评价由所述服务节点导致所述运维***出现***异常的可能性程度；
节点筛选单元，基于所述评价结果，从所述多个服务节点中确定出根因节点；
其中，所述根因节点为导致所述运维***出现***异常，以触发所述根因定位指令的异常服务节点。
第三方面，本申请还提供了一种计算机设备，包括：
处理器；
用于存储所述处理器的可执行指令的存储器；
其中，所述处理器被配置为执行所述可执行指令，以实现如上所述的根因定位方法。
第四方面，本申请还提供了一种计算机可读存储介质。所述计算机可读存储介质中包括程序数据，当所述程序数据被执行时，实现如上所述的根因定位方法。
第五方面，本申请还提供了一种计算机程序产品。所述计算机程序产品中包括程序指令，当所述程序指令被执行时，实现如上所述的根因定位方法。
上述根因定位方法、根因定位装置、计算机设备、计算机可读存储介质和计算机程序产品，先通过响应运维***触发根因定位指令，确定在当前时间窗口内运维***响应的多个服务节点；其中，在各服务节点中分别包括有至少一个服务请求，运维***用于执行至少一个服务请求，以实现服务节点对应的服务功能；获取运维***在分别执行各服务节点的服务请求时，对应产生的运维数据；基于运维数据，分别对各服务节点进行根因评价，得到针对各服务节点的评价结果；根因评价用于评价由服务节点导致运维***出现***异常的可能性程度；基于评价结果，从多个服务节点中确定出根因节点；其中，根因节点为导致运维***出现***异常，以触发根因定位指令的异常服务节点。这样，一方面，通过区别于现有技术的方式，本方案通过在运维***触发根因定位指令时，首先确定运维***响应的多个服务节点，然后再获取各个服务节点对应的运维数据，最后再利用运维数据对各个服务节点进行根因评价，以在多个服务节点中定位出根因节点，从而优化了根因定位的流程，有效提高了对故障***进行根因定位的效率，降低了人力和物力的消耗；另一方面，本方案通过在运维***出现***异常时，先在当前时间窗口内确定受到异常影响的多个服务节点，然后再利用运维***在执行各个服务节点对应的服务请求时所产生的运维数据，来对由服务节点导致***异常的可能性程度进行评价，以确定出异常的根因节点，从而优化了对服务节点进行根因定位的方式，有效提高了根因定位的合理性和准确性，有利于后续及时的修复***异常。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。
图1是根据一示例性实施例示出的一种根因定位方法的应用环境图。
图2是根据一示例性实施例示出的一种根因定位方法的流程图。
图3是根据一示例性实施例示出的一种运维***触发根因定位指令步骤的流程图。
图4是根据一示例性实施例示出的一种从服务节点中确定出根因节点步骤的流程图。
图5是根据一示例性实施例示出的一种对服务节点进行根因评价步骤的流程图。
图6是根据一示例性实施例示出的一种确定性能指标的实时状态步骤的流程图。
图7是根据另一示例性实施例示出的一种根因定位方法的流程图。
图8是根据另一示例性实施例示出的一种根因定位方法的模块图。
图9是根据一示例性实施例示出的一种根因定位装置框图。
图10是根据一示例性实施例示出的一种用于根因定位的计算机设备的框图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
本申请中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，尽管多次采用术语“第一”、“第二”等来描述各种操作(或各种阈值或各种应用或各种指令或各种元件)等，不过这些操作(或阈值或应用或指令或元件)不应受这些术语的限制。这些术语只是用于区分一个操作(或阈值或应用或指令或元件)和另一个操作(或阈值或应用或指令或元件)。
本申请实施例提供的根因定位方法，可以应用于如图1所示的应用环境中。其中，终端102通过通信网络与服务器104进行通信。数据存储***可以存储服务器104需要处理的数据。数据存储***可以集成在服务器104上，也可以放在云上或其他网络服务器上。
在一些实施例中，参考图1，首先，服务器104响应运维***触发根因定位指令，确定在当前时间窗口内运维***响应的多个服务节点；其中，在各服务节点中分别包括有至少一个服务请求，运维***用于执行至少一个服务请求，以实现服务节点对应的服务功能；然后，服务器104再获取运维***在分别执行各服务节点的服务请求时，对应产生的运维数据；然后，服务器104再基于运维数据，分别对各服务节点进行根因评价，得到针对各服务节点的评价结果；根因评价用于评价由服务节点导致运维***出现***异常的可能性程度；最后，服务器104基于评价结果，从多个服务节点中确定出根因节点；其中，根因节点为导致运维***出现***异常，以触发根因定位指令的异常服务节点。
在一些实施例中，终端102(如移动终端、固定终端)可以以各种形式来实施。其中，终端102可为包括诸如移动电话、智能电话、笔记本电脑、便携式手持式设备、个人数字助理(PDA，Personal Digital Assistant)、平板电脑(PAD)等等的移动终端，终端102也可以是自动柜员机(Automated Teller Machine，ATM)、自动一体机、数字TV、台式计算机、固式计算机等等的固定终端。
下面，假设终端102是固定终端。然而，本领域技术人员将理解的是，若有特别用于移动目的的操作或者元件，根据本申请公开的实施方式的构造也能够应用于移动类型的终端102。
在一些实施例中，服务器104运行的数据处理组件可以加载正在被执行的可以包括各种附加服务器应用和/或中间层应用中的任何一种，如包括HTTP(超文本传输协议)、FTP(文件传输协议)、CGI(通用网关界面)、RDBMS(关系型数据库管理***)等。
在一些实施例中，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。服务器104可以适于运行提供前述公开中描述的终端102的一个或多个应用服务或软件组件。
在一些实施例中，应用服务可以包括向用户提供根因定位的服务界面，以及对应程序服务等等。其中，软件组件可以包括执行根因定位功能的应用程序(SDK)或者客户端(APP)。
在一些实施例中，服务器104所提供的具有根因定位功能的应用程序或者客户端包括一个在前台向用户提供一对一应用服务的门户端口和多个位于后台进行数据处理的业务***，以将根因定位功能应用扩展到APP或者客户端，从而用户能够在任何时间任何地点执行根因定位功能的使用和访问。
在一些实施例中，用户可以通过预设的输入装置或者自动控制程序向APP或者客户端输入相应的代码数据或者控制参数，以执行服务器104中的计算机程序的应用服务，以及显示用户界面中的应用服务。
在一些实施例中，APP或者客户端运行的操作***可以包括各种版本的MicrosoftApple/>和/或Linux操作***、各种商用或类/>操作***(包括但不限于各种GNU/Linux操作***、Google/>OS等)和/或移动操作***，诸如Phone、/>OS、/>OS、/>OS操作***，以及其它在线操作***或者离线操作***，在这里不做具体的限制。
在一个实施例中，如图2所示，提供了一种根因定位方法，以该方法应用于图1中的服务器为例进行说明，具体包括以下步骤：
步骤S11：响应运维***触发根因定位指令，确定在当前时间窗口内运维***响应的多个服务节点。
在一实施例中，基于服务器预先配置的监控任务，当服务器监控到运维***出现***故障、***异常时，服务器自动响应运维***触发根因定位指令，以开始执行根因定位任务。
在一种实施例中，服务器响应运维***触发根因定位指令，可以包括以下步骤：
步骤一：获取终端用户发起的故障告警。
步骤二：响应于在当前滑动时间窗内，故障告警的数量大于预设数量，自动触发根因定位指令。
作为示例，服务器首先实时的获取终端用户针对“客服***”发送的故障告警(即用户端提交的故障报告)，然后服务器再检测到在当前滑动时间窗内接收到针对“客服***”的故障告警的数量。其中，该当前滑动时间窗为以当前时刻为终点时间且时间长度为10分钟的当前滑动时间窗口，服务器对应接收到故障报告分别包括故障告警X1、故障告警X2、故障告警X3、故障告警X4、故障告警X5共5条。其中，服务器针对故障告警预先设置的阈值数量为4条，因此在该当前滑动时间窗内，服务器接收到的故障告警的数量已超过预设数量，从而服务器对“客服***”自动触发根因定位指令。
在一示例性实施例中，如图3所示，图3为本申请中运维***触发根因定位指令一实施例的界面示意图。其中，该界面为服务器用于监控运维***正异常状态的后台监控界面S1，在后台监控界面S1中包括对象类型显示区S2、对象信息显示区S3、告警级别显示区S4、告警时间显示区S5和告警内容显示区S6。其中，在对象类型显示区S2中显示有服务器监控运维***中的监控对象“客服***”，在对象信息显示区S3中显示有“客服***”相关的***信息，在告警级别显示区S4中显示有当前服务器对“客服***”划分的告警级别“中级”，在告警时间显示区S5中显示有服务器在为“客服***”划分告警级别时的时间，在告警内容显示区S6中显示有服务器接收到终端用户发送的故障告警X1、故障告警X2、故障告警X3、故障告警X4、故障告警X5。
在一实施例中，运维***触发的根因定位指令用于首先确定在当前时间窗口内运维***响应的多个服务节点；然后再根据服务节点对异常的运维***进行异常原因的分析，以确定出导致运维***出现异常的根因节点，从而对该根因节点进行修复，以使运维***恢复正常。
其中，当前时间窗口为以触发根因定位指令时的时刻为终点时间且时间长度为预设长度的固定长度时间窗口。例如，固定长度时间窗口为3个小时的时间长度，该运维***在今日的16:00触发根因定位指令，从而服务器确定出在今日的13:00-16:00之间运维***响应的全部服务节点。
在一实施例中，服务节点是运维***实现某单一功能的实体模块或抽象模块，其包括如微服务、服务器、中间件、业务应用、业务模块等。
其中，在运维***响应的各服务节点中，每个服务节点均包括有对应的至少一个服务请求，且运维***用于执行该至少一个服务请求，以实现服务节点对应的服务功能。
步骤S12：获取运维***在分别执行各服务节点的服务请求时，对应产生的运维数据。
具体地，在运维***执行服务节点的服务请求时，产生了对应的运维数据；然后，服务器将这些运维数据分别存储于相应的存储介质中，以在运维***响应根因定位指令时，从对应的存储介质中提取出待用的运维数据。
在一些实施例中，运维***在执行各种服务节点的服务请求时，其对应产生的运维数据的类型有多种。包括如“代码逻辑”类型、“变更”类型、“第三方应用”类型、“***基础设施”类型、“***架构设计”类型、“***具体应用”类型等多种。
其中，基于运维工程师对一长时间跨度(如365天时长)内运维***产生的全部运维数据的统计，确定“变更”类型、“***基础设施”类型和“***具体应用”类型的运维数据的数量占据该全部运维数据的数量的90％以上。因此，通过服务器在该多种运维数据中，将“变更”类型、“***基础设施”类型和“***具体应用”类型的运维数据设置为核心运维数据。
进一步地，在某些实施例中，服务器获取运维***在分别执行各个服务节点的服务请求对应所产生的运维数据，可以为“变更”类型、“***基础设施”类型和“***具体应用”类型的运维数据。
步骤S13：基于运维数据，分别对各服务节点进行根因评价，得到针对各服务节点的评价结果。
在一实施例中，根因评价用于评价由服务节点导致运维***出现***异常的可能性程度。
在一些实施例中，服务器将各个服务节点对应的运维数据输入到预训练的根因定位模型中进行根因评价，以输出针对各个服务节点的评价分数，然后服务器再将评价分数作为服务节点的评价结果。
其中，该根因定位模型用于预测服务节点在多维度导致运维***出现***异常的可能性分数，并输出对应各个维度之间预测的总分数。
在一些实施例中，根因定位模型可以是一种神经网络(如CNN、VGG、ResNet等)模型、语义分割(如Transformer、基于Attention的RNN、LSTM等)模型等。
在某些实施例中，根因定位模型可以是一种机器学习模型。其中，机器学习模型通过学习大量的训练数据采取的不同入参数据(即训练数据的数值)后得到的累积反馈值，以得到不同的行动策略(即不同类型的运维数据的数值)在每个初始入参数据下最优的反馈值范围(即模型的学习参数的最优预测分数范围)。
步骤S14：基于评价结果，从多个服务节点中确定出根因节点。
在一实施例中，服务器从多个服务节点中确定出根因节点，包括：在各个服务节点，将对应总分数最高的目标服务节点作为根因节点。
其中，根因节点为导致运维***出现***异常，以触发根因定位指令的异常服务节点。
作为示例，服务器首先获取“客服***”在最近3个小时内响应的多个服务节点P1-P5，然后服务器再分别确定对服务节点P1进行根因评价的总分数为0.65分、对服务节点P2进行根因评价的总分数为0.60分、对服务节点P3进行根因评价的总分数为0.47分、对服务节点P4进行根因评价的总分数为0.55分和对服务节点P5进行根因评价的总分数为0.59分。最后服务器从服务节点P1-P5中选择出对应总分数最高的服务节点P1作为根因节点。
在一示例性实施例中，如图4所示，图4为本申请中从服务节点中确定出根因节点一实施例的界面示意图。其中，该界面为服务器用于展示根因定位结果的结果展示界面L1，在结果展示界面L1中包括对象类型显示区L2、根因节点显示区L3、异常描述显示区L4、异常时间显示区L5、根因分数显示区L6和根因排名显示区L7。其中，在对象类型显示区L2中显示有服务器监控运维***中的监控对象“客服***”，在根因节点显示区L3中显示有对应确定的根因节点：“服务节点P1”，在异常描述显示区L4中显示有针对当前“客服***”异常的描述信息，在异常时间显示区L5中显示有服务器在为“客服***”被判断为异常时的时间，在根因分数显示区L6中显示有对“服务节点P1”进行根因评价的总分数0.65分，在根因排名显示区L7中显示有“服务节点P1”在所有的服务节点中对应根因评价的总分数排名为第一名。
上述的根因定位过程中，服务器响应运维***触发根因定位指令，确定在当前时间窗口内运维***响应的多个服务节点；其中，在各服务节点中分别包括有至少一个服务请求，运维***用于执行至少一个服务请求，以实现服务节点对应的服务功能；获取运维***在分别执行各服务节点的服务请求时，对应产生的运维数据；基于运维数据，分别对各服务节点进行根因评价，得到针对各服务节点的评价结果；根因评价用于评价由服务节点导致运维***出现***异常的可能性程度；基于评价结果，从多个服务节点中确定出根因节点；其中，根因节点为导致运维***出现***异常，以触发根因定位指令的异常服务节点。这样，一方面，通过区别于现有技术的方式，本方案通过在运维***触发根因定位指令时，首先确定运维***响应的多个服务节点，然后再获取各个服务节点对应的运维数据，最后再利用运维数据对各个服务节点进行根因评价，以在多个服务节点中定位出根因节点，从而优化了根因定位的流程，有效提高了对故障***进行根因定位的效率，降低了人力和物力的消耗；另一方面，本方案通过在运维***出现***异常时，先在当前时间窗口内确定受到异常影响的多个服务节点，然后再利用运维***在执行各个服务节点对应的服务请求时所产生的运维数据，来对由服务节点导致***异常的可能性程度进行评价，以确定出异常的根因节点，从而优化了对服务节点进行根因定位的方式，有效提高了根因定位的合理性和准确性，有利于后续及时的修复***异常。
本领域技术人员可以理解地，在具体实施方式的上述方法中，所揭露的方法可以通过更为具体的方式以实现。例如，以上所描述的服务器基于运维数据，分别对各服务节点进行根因评价，得到针对各服务节点的评价结果的实施方式仅仅是示意性的。
示例性地，服务器确定在当前时间窗口内运维***响应的多个服务节点的方式；或者，服务器从多个服务节点中确定出根因节点的方式等等，其仅仅为一种集合的方式，实际实现时可以有另外的划分方式，例如当前时间窗口内的多个服务节点、多个服务节点中的根因节点之间可以结合或者可以集合到另一个***中，或一些特征可以忽略，或不执行。
在一示例性实施例中，参阅图5，图5为本申请中对服务节点进行根因评价一实施例的流程示意图。即在步骤S13中，服务器基于运维数据，分别对各服务节点进行根因评价，得到针对各服务节点的评价结果的过程，具体可以通过执行以下方式实现：
步骤S131：基于运维数据，确定运维***在分别响应各服务节点时的性能指标和功能指标。
在一些实施例中，性能指标至少包括运维***在响应服务节点时的P99耗时、日志错误率、请求失败率和数据故障率。
其中，性能指标用于表征运维***在响应服务节点时的***性能状况，并且服务节点的性能指标还表征有其对应的指标值。
其中，P99耗时表征运维***在响应服务节点时，运维***对应执行99％的服务请求所用的耗时是处于多少毫秒以内。
作为示例，运维***在响应服务节点A1时，运维***对应所执行的99％的服务请求所用的耗时均处于250ms以内，则服务节点A1对应P99耗时的指标值为250ms。
其中，日志错误率表征运维***在响应服务节点时，在对应生成的日志文件中，存在关键字“error”的日志数据的比例。
作为示例，运维***在响应服务节点A2时，运维***对应生成有100条日志数据且均存储于日志文件中，且在该100条日志数据中有10条日志数据存在关键字“error”，则服务节点A2对应的日志错误率的指标值为10％。
其中，请求失败率表征运维***在响应服务节点时，在对应处理的所有服务请求中，处理失败的服务请求的比例。
作为示例，运维***在响应服务节点A3时，运维***对应处理有10个服务请求，且在该10个服务请求中有2个服务请求处理失败，则网络节点A3对应的处理服务请求的失败率的指标值为20％。
其中，数据故障率表征运维***在响应服务节点时，对应生成的故障数据占据最近3小时内全部故障数据的比例。
作为示例，运维***在响应服务节点A4时，系运维统对应产生有30条“变更”类型的故障数据、20条“基础设施”类型的故障数据和20条“核心应用”类型的故障数据；以及运维***在最近3小时内，***共产生有100条故障数据，从而在该100条故障数据中，针对服务节点A4对应的数据故障率的指标值分别为30％、20％和20％。
在一些实施例中，功能指标至少包括运维***在响应服务节点时的应用人数比例、异常应用比例、对应产生变更类型的运维数据的数量。
其中，功能占比表用于表征运维***在响应服务节点时所应用的功能服务状况，并且服务节点的功能指标还表征有其对应的指标值。
其中，变更类型的运维数据的数量表征运维***在响应服务节点时，在对应产生的所有运维数据中，属于“变更”类型的运维数据的数量。
作为示例，运维***在响应服务节点A5时，运维***对应产生有100条“变更”类型的运维数据；以及运维***在最近3小时内，运维***共产生有1000条运维数据，从而在该1000条运维数据中，针对服务节点A5对应的变更数据的数量的指标值为10％。
其中，应用人数比例表征运维***在响应服务节点时，运维***当前调用的当前应用的使用人数占据在对应3个小时内使用人数最多的目标应用的使用人数的比例。
其中，当前应用与目标应用可以为相同的应用程序，也可以为不相同的应用程序。
其中，应用程序的使用人数用于衡量应用程序的故障影响面，如果应用程序的使用人数比较低，则在应用程序出行故障时，其影响的用户数量也较少。
作为示例，运维***在最近3个小时内共调用了20个应用程序，其中，对应使用人数最多的目标应用的使用人数为1000人；运维***在响应服务节点A6时，其当前调用的当前应用的使用人数为200人，从而服务节点A6的应用人数比例的指标值为20％。
其中，异常应用比例表征运维***在响应服务节点时，运维***基于调用链所调用的异常应用占据全部应用的比例。
作为示例，运维***在响应服务节点A7时，运维***基于服务节点A7的调用链共调用了20个应用程序，其中，对应属于异常应用的数量为10个，从而服务节点A7的异常应用比例的指标值为50％。
在一实施例中，在服务器确定运维***在分别响应各服务节点时的性能指标之后还需要确定运维***在响应服务节点时性能指标的正异常状态，以根据性能指标的正异常状态对服务节点进行评价。
在一示例性实施例中，参阅图6，图6为本申请中确定性能指标的实时状态一实施例的流程示意图。在步骤S131之后，即服务器在确定运维***在分别响应各服务节点时的性能指标之后，还可以执行以下方式：
步骤a1：获取运维***在历史时间窗口内响应的历史服务节点的历史性能指标的历史指标值。
其中，历史时间窗口包括当前时间窗口，例如，当前时间窗口为以触发根因定位指令时的时刻为终点时间且时间长度为3小时的时间窗口，而历史时间窗口为以触发根因定位指令时的时刻为终点时间且时间长度为72小时的时间窗口。因此，运维***在历史时间窗口内响应的历史服务节点包括运维***在当前时间窗口内响应的全部服务节点，且历史服务节点的数量不少于当前响应的全部服务节点。
步骤a2：将历史性能指标的历史指标值输入预训练的指标预测模型中进行安全性能预测，得到预测的安全性能区间。
在一实施例中，指标预测模型预测的安全性能区间为一个针对性能指标值的安全区间，且该安全性能区间具有预设大小的有效时长。
作为示例，一预测的安全性能区间表示为(x1,x2；60min)，其中，“x1”为安全性能区间的下边界，“x2”为安全性能区间的上边界，“60min”为安全性能区间的有效时长，即在指标预测模型输出该安全性能区间之后的60分钟内，该安全性能区间为有参考价值的有效区间。
步骤a3：基于当前时间窗口内的各服务节点的性能指标的指标值与安全性能区间之间的大小关系，确定各服务节点的性能指标的实时状态。
在一实施例中，服务器确定各服务节点的性能指标的实时状态，包括以下两种情况：
情况一：在预设时间长度内，若服务节点的性能指标的指标值均处于安全性能区间内，则确定服务节点的性能指标在预设时间长度内的实时状态为正常状态。
情况二：在预设时间长度内，若服务节点的性能指标的指标值均未处于安全性能区间内，则确定服务节点的性能指标在预设时间长度内的实时状态为异常状态。
其中，该预设时间长度小于安全性能区间的有效时长
针对情况一，在一个示例中，安全性能区间为(x1,x2；60min)，预设时间长度为5min。若某服务节点的性能指标的指标值在一个连续的5min内均处于区间(x1，x2)内，则该服务节点的性能指标在该连续的5min内的实时状态为正常状态。
针对情况二，在一个示例中，安全性能区间为(x3,x4；120min)，预设时间长度为10min。若某服务节点的性能指标的指标值在一个连续的10min内均未处于区间(x3，x4)内，则该服务节点的性能指标在该连续的10min内的实时状态为异常状态。
步骤S132：基于预设的分数因子，对各服务节点的性能指标进行第一评分，得到针对性能指标的第一评价分数。
在一些实施例中，服务器对各服务节点的性能指标进行第一评分，得到针对性能指标的第一评价分数，包括：将对应实时状态的性能指标的分数因子作为针对性能指标的第一评价分数。
其中，不同实时状态的性能指标对应预设有不同的分数因子。
作为一种示例，基于运维专家经验，服务器配置正常状态的P99耗时预设的分数因子为0分，异常状态的P99耗时预设的分数因子为0.25分，其对应的第一评分为对应实时状态的分数因子的值，即若某服务节点的P99耗时属于正常状态，则针对该P99耗时的第一评价分数为0分；若某服务节点的P99耗时属于异常状态，则针对该P99耗时的第一评价分数为0.25分。
作为另一种示例，基于运维专家经验，服务器配置正常状态的日志错误率预设的分数因子为0分，异常状态的日志错误率预设的分数因子为0.1分，其对应的第一评分为对应实时状态的分数因子的值，即若某服务节点的日志错误率属于正常状态，则针对该日志错误率的第一评价分数为0分；若某服务节点的日志错误率属于异常状态，则针对该日志错误率的第一评价分数为0.1分。
作为另一种示例，基于运维专家经验，服务器配置正常状态的请求失败率和数据故障率预设的分数因子均为0分，异常状态的请求失败率和数据故障率预设的分数因子均为0.15分，其对应的第一评分均为对应实时状态的分数因子，即若某服务节点的请求失败率或数据故障率属于正常状态，则针对该请求失败率或数据故障率的第一评价分数为0分；若某服务节点的请求失败率或数据故障率属于异常状态，则针对该请求失败率或数据故障率的第一评价分数为0.15分。
步骤S133：基于预设的权重因子，对各服务节点的功能指标进行第二评分，得到针对功能指标的第二评价分数。
在一些实施例中，服务器对各服务节点的功能指标进行第二评分，得到针对功能指标的第二评价分数，包括：将功能指标的指标值与对应权重因子之间的乘积值作为针对性能指标的第一评价分数。
其中，不同的功能指标对应预设有不同的权重因子。
作为一示例，基于运维专家经验，服务器对“变更”类型的运维数据预设的权重因子为0.25，其对应的第二评分为变更数据的数量和权重因子之间的乘积；即若某服务节点包括“变更”类型的运维数据的数量为X条，则针对该“变更”类型运维数据的数量的第二评价分数为X×0.25分。
作为一示例，基于运维专家经验，服务器对应用人数比例预设的权重因子为0.1，其对应的第二评分为应用人数比例和权重因子之间的乘积；即若某服务节点对应的应用人数比例为S1，则针对该应用人数比例的第二评价分数为S1×0.1分。
作为一示例，基于运维专家经验，服务器对异常应用比例预设的权重因子为0.15，其对应的第二评分为异常应用比例和权重因子之间的乘积；即若某服务节点对应的异常应用比例为S2，则针对该异常应用比例的第二评价分数为S2×0.15分。
步骤S134：基于第一评价分数和第二评价分数，确定针对各服务节点的评价结果。
在一些实施例中，服务器确定针对各服务节点的评价结果，包括：针对每一服务节点，确定各个性能指标的第一评价分数和将各个功能指标的第二评价分数之间的总分数，并将总分数作为服务节点的评价结果。
作为示例，针对某服务节点P，其关于性能指标的第一评价分数包括P99耗时的0.25分、日志错误率的0.1分、请求失败率的0.15分和数据故障率的0.15分，以及功能指标的第二评价分数包括“变更”类型运维数据的数量的X×0.25分、应用人数比例的S1×0.1分、异常应用比例的S2×0.15分，从而该服务节点P的总分数为0.25+0.1+0.15+0.15+X×0.25+S1×0.1+S2×0.15分，并且该总分数即为服务节点P的评价结果。其中，“X”、“S1”和“S2”均为常数。
为了更清晰阐明本公开实施例提供的根因定位方法，以下以一个具体的实施例对该根因定位方法进行具体说明。在一示例性实施例中，参考图7和图8，图7为根据一示例性实施例示出的一种根因定位方法的流程图，图8为根据一示例性实施例示出的一种根因定位方法的模块图，该根因定位方法用于服务器中，具体包括如下内容：
步骤S21：响应满足根因定位的触发条件，***自动触发根因定位的执行程序。
其中，根因定位的触发条件包括以下两种：
①在最近10分钟内收到用户的报障次数达到阈值，运维***发出告警，从而触发根因定位；②用户自己在根因定位操作界面中输入一个时间点，并点击确认，以指示运维***触发根因定位。
其中，根因定位的执行程序可以通过一个经过预训练的根因定位模型来执行，其用于对出现故障的运维***进行根因节点的定位。其中，该根因定位的执行程序包括以下步骤S22至步骤S28的过程。
步骤S22：确定***在最近3个小时内响应的网络节点。
其中，网络节点是运维***中实现单一功能的实体模块或抽象模块，例如微服务、服务器、中间件、业务应用、业务模块等。
其中，在每个网络节点中包括***执行的多个服务请求。
步骤S23：从数据仓库中，采集***在分别响应各个网络节点时所产生的主要类型的运维数据。
其中，主要类型的运维数据包括“变更”类型、“基础设施”类型和“具体应用”类型三种类型的运维数据。
其中，采集“变更”类型的运维数据包括：采集发布平台中的发布数据、跳板机中记录的关于编辑代码的审计数据、作业平台中执行的脚本数据、用于对数据库(数据表)的变更数据、各种运营事件的变更数据、在重点变更通知群中的发布数据。
其中，针对重点变更通知群中的发布数据，工程师首先在编辑页面中，编辑发布内容；然后，再将发布内容上传到“重点变更通知群”中进行内容发布；最后，***将发布内容存储在预设的事件中心平台中存储。
其中，“重点变更通知群”为如钉钉、微信、QQ等社交应用中的虚拟群聊房间；事件中心平台为一个用于存储数据的数据库。
其中，采集“基础设施”类型的运维数据包括：采集DNS中的存储数据、网络专线数据、LB数据、NAT网络数据，DB数据(包括kafka中的数据、Etcd中的数据、MongoDb中的数据等)等、第三方云厂商的云数据，k8s中的数据，istio中的数据。
其中，采集“核心应用”类型的运维数据包括：采集预设的多个应用程序产生的程序数据和调用链数据。
步骤S24：根据运维数据，确定***分别在响应各个网络节点时的健康指标、变更数据的数量、Qps比例、异常应用比例。
其中，网络节点的健康指标包括P99耗时、日志错误率、处理服务请求的失败率和历史故障概率。
其中，P99耗时表征***在响应网络节点时，***对应执行99％的服务请求所用的耗时是处于多少毫秒以内。
作为示例，***在响应网络节点A1时，***对应所执行的99％的服务请求所用的耗时均处于250ms以内，则网络节点A1对应的P99耗时为250ms。
其中，日志失败率表征***在响应网络节点时，在对应生成的日志文件中，存在关键字“error”的日志数据的比例。
作为示例，***在响应网络节点A2时，***对应生成有100条日志数据且均存储于日志文件中，且在该100条日志数据中有30条日志数据存在关键字“error”，则网络节点A2对应的日志失败率为30％。
其中，处理服务请求的失败率表征***在响应网络节点时，在对应处理的所有服务请求中，处理失败的服务请求的比例。
作为示例，***在响应网络节点A3时，***对应处理有10个服务请求，且在该10个服务请求中有2个服务请求处理失败，则网络节点A3对应的处理服务请求的失败率为20％。
其中，历史故障概率表征***在响应网络节点时，对应生成的属于“变更”类型的故障数据占据最近3小时内全部故障数据的比例；和/或，对于生成的属于“基础设施”类型的故障数据占据最近3小时内全部故障数据的比例；和/或，对于生成的属于“核心应用”类型的故障数据占据最近3小时内全部故障数据的比例。
作为示例，***在响应网络节点A4时，***对应产生有30条“变更”类型的故障数据、20条“基础设施”类型的故障数据和20条“核心应用”类型的故障数据；以及***在最近3小时内，***共产生有100条故障数据，从而在该100条故障数据中，针对网络节点A4对应的历史故障概率分别为30％、20％和20％。
其中，变更数据的数量表征***在响应网络节点时，在对应产生的所有运维数据中，属于“变更”类型的运维数据的数量。
作为示例，***在响应网络节点A5时，***对应产生有100条“变更”类型的运维数据；以及***在最近3小时内，***共产生有1000条运维数据，从而在该1000条运维数据中，针对网络节点A5对应的变更数据的数量为10％。
其中，Qps比例表征***在响应网络节点时，***当前调用的当前应用的使用人数占据在对应3个小时内使用人数最多的目标应用的使用人数的比例。
其中，当前应用与目标应用可以为相同的应用程序，也可以为不相同的应用程序。
其中，应用程序的使用人数用于衡量应用程序的故障影响面，如果应用程序的使用人数比较低，则在应用程序出行故障时，其影响的用户数量也较少。
作为示例，***在最近3个小时内共调用了20个应用程序，其中，对应使用人数最多的目标应用的使用人数为1000人；***在响应网络节点A6时，其当前调用的当前应用的使用人数为200人，从而网络节点A6的Qps比例为20％。
其中，异常应用比例表征***在响应网络节点时，***基于调用链所调用的异常应用占据全部应用的比例。
作为示例，***在响应网络节点A7时，***基于网络节点A7的调用链共调用了20个应用程序，其中，对应属于异常应用的数量为10个，从而网络节点A7的异常应用比例为50％。
步骤S25：对各个网络节点所对应的健康指标进行状态判断，确定各个健康指标的实时状态。
其中，网络节点对应的健康指标的实时状态包括正常状态或者异常状态。
其中，状态判断的过程包括：①从数据仓库Prometheus中提取当前时间戳往前5天内的历史网络节点；②获取各个历史网络节点的时间戳和健康指标值；③将各个历史网络节点的时间戳和健康指标值送进预训练的Prophet时间序列模型进行区间预测，以输出预测的安全值区间；其中，安全值区间表征网络节点的健康指标值在未来的一个小时内对应所属的安全值的区间；④将最近3个小时内的各个网络节点所对应的健康指标值与安全值区间作实时对比；⑤若网络节点所对应的健康指标值在连续的5分钟内均处于在安全值区间之外，则确定对应的健康指标的实时状态为异常状态；若网络节点所对应的健康指标值在连续的5分钟内均处于在安全值区间之内，则确定对应的健康指标的实时状态为正常状态。
步骤S26：基于预设的分数因子和健康指标的实时状态，确定针对每一个网络节点的健康指标的第一分数；以及，基于预设的权重因子，确定针对每一个网络节点的变更数据的数量、Qps比例和异常应用比例各自的第二分数。
作为一示例，基于运维专家经验，对健康指标中正常状态的P99耗时预设的分数因子为0分，异常状态的P99耗时预设的分数因子为0.25分，其对应的第一评分为对应实时状态的分数因子；正常状态的日志错误率预设的分数因子为0分，异常状态的日志错误率预设的分数因子为0.1分，其对应的第一评分为对应实时状态的分数因子；正常状态的处理服务请求的失败率和历史故障概率预设的分数因子均为0分，异常状态的处理服务请求的失败率和历史故障概率预设的分数因子均为0.15分，其对应的第一评分均为对应实时状态的分数因子。
作为另一示例，基于运维专家经验，对“变更”类型的运维数据预设的权重因子为0.25，其对应的第二评分为变更数据的数量和权重因子之间的乘积；对Qps比例预设的权重因子为0.1，其对应的第二评分为Qps比例和权重因子之间的乘积；对异常应用比例预设的权重因子为0.15，其对应的第二评分为异常应用比例和权重因子之间的乘积。
步骤S27：基于网络节点的各个第一分数和第二分数之间的和值，确定针对各网络节点的总分数。
步骤S28：在各个网络节点中，将对应总分数最高的目标网络节点作为***故障的根因节点。
其中，在服务器通过根因定位的执行程序确定出导致运维***出现故障的根因节点之后，运维工程师还可以再对根因节点进行检测，以确定根因节点是否准确，从而对每一个根因节点进行有效性的标记。
这样，一方面，通过区别于现有技术的方式，本方案通过在运维***触发根因定位指令时，首先确定运维***响应的多个服务节点，然后再获取各个服务节点对应的运维数据，最后再利用运维数据对各个服务节点进行根因评价，以在多个服务节点中定位出根因节点，从而优化了根因定位的流程，有效提高了对故障***进行根因定位的效率，降低了人力和物力的消耗；另一方面，本方案通过在运维***出现***异常时，先在当前时间窗口内确定受到异常影响的多个服务节点，然后再利用运维***在执行各个服务节点对应的服务请求时所产生的运维数据，来对由服务节点导致***异常的可能性程度进行评价，以确定出异常的根因节点，从而优化了对服务节点进行根因定位的方式，有效提高了根因定位的合理性和准确性，有利于后续及时的修复***异常。
应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的根因定位方法所对应的根因定位装置。该根因定位装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个装置实施例中的具体限定可以参见上文中对于用户信息的识别方法和多端用户的交互方法的限定，在此不再赘述。
在一个实施例中，如图9所示，提供了一种根因定位装置10，包括：指令触发单元11、数据获取单元12、节点评价单元13和节点筛选单元14，其中：
指令触发单元11，被配置为执行响应运维***触发根因定位指令，确定在当前时间窗口内所述运维***响应的多个服务节点；其中，在各所述服务节点中分别包括有至少一个服务请求，所述运维***用于执行所述至少一个服务请求，以实现所述服务节点对应的服务功能；
数据获取单元12，被配置为执行获取所述运维***在分别执行各所述服务节点的服务请求时，对应产生的运维数据；
节点评价单元13，被配置为执行基于所述运维数据，分别对各所述服务节点进行根因评价，得到针对各所述服务节点的评价结果；所述根因评价用于评价由所述服务节点导致所述运维***出现***异常的可能性程度；
节点筛选单元14，基于所述评价结果，从所述多个服务节点中确定出根因节点；
其中，所述根因节点为导致所述运维***出现***异常，以触发所述根因定位指令的异常服务节点。
在一些实施例中，所述基于所述运维数据，分别对各所述服务节点进行根因评价，得到针对各所述服务节点的评价结果，包括：
基于所述运维数据，确定所述运维***在分别响应各所述服务节点时的性能指标和功能指标；所述性能指标用于表征所述运维***在响应服务节点时的***性能状况，所述功能指标用于表征所述运维***在响应服务节点时所应用的功能服务状况；
基于预设的分数因子，对各所述服务节点的性能指标进行第一评分，得到针对所述性能指标的第一评价分数；以及
基于预设的权重因子，对各所述服务节点的功能指标进行第二评分，得到针对所述功能指标的第二评价分数；
基于所述第一评价分数和所述第二评价分数，确定针对各所述服务节点的评价结果。
在一些实施例中，所述性能指标表征有对应的指标值；
在确定所述运维***在分别响应各所述服务节点时的性能指标之后，还包括：
获取所述运维***在历史时间窗口内响应的历史服务节点的历史性能指标的历史指标值；所述历史时间窗口包括所述当前时间窗口；
将所述历史性能指标的历史指标值输入预训练的指标预测模型中进行安全性能预测，得到预测的安全性能区间；
基于所述当前时间窗口内的各所述服务节点的性能指标的指标值与所述安全性能区间之间的大小关系，确定各所述服务节点的性能指标的实时状态。
在一些实施例中，所述基于所述当前时间窗口内的各所述服务节点的性能指标的指标值与所述安全性能区间之间的大小关系，确定各所述服务节点的性能指标的实时状态，包括以下两项：
在预设时间长度内，若所述服务节点的性能指标的指标值均处于所述安全性能区间内，则确定所述服务节点的性能指标在所述预设时间长度内的实时状态为正常状态；
在预设时间长度内，若所述服务节点的性能指标的指标值均未处于所述安全性能区间内，则确定所述服务节点的性能指标在所述预设时间长度内的实时状态为异常状态。
在一些实施例中，所述基于预设的分数因子，对各所述服务节点的性能指标进行第一评分，得到针对所述性能指标的第一评价分数，包括：
将对应所述实时状态的性能指标的分数因子作为针对所述性能指标的第一评价分数；
其中，不同所述实时状态的性能指标对应预设有不同的分数因子。
在一些实施例中，所述功能指标表征有对应的指标值；
所述基于预设的权重因子，对各所述服务节点的功能指标进行第二评分，得到针对所述功能指标的第二评价分数，包括：
将所述功能指标的指标值与对应权重因子之间的乘积值作为针对所述性能指标的第一评价分数；
其中，不同的所述功能指标对应预设有不同的权重因子。
在一些实施例中，所述性能指标至少包括所述运维***在响应服务节点时的P99耗时、日志错误率、请求失败率和数据故障率；所述功能指标至少包括所述运维***在响应服务节点时的应用人数比例、异常应用比例、对应产生变更类型的运维数据的数量；
所述基于所述第一评价分数和所述第二评价分数，确定针对各所述服务节点的评价结果，包括：
针对每一所述服务节点，确定各个性能指标的第一评价分数和将各个功能指标的第二评价分数之间的总分数，并将所述总分数作为所述服务节点的评价结果。
在一些实施例中，所述基于所述评价结果，从所述多个服务节点中确定出根因节点，包括：
在各个所述服务节点，将对应所述总分数最高的目标服务节点作为根因节点。
在一些实施例中，所述响应所述运维***触发根因定位指令，包括：
获取终端用户发起的故障告警；
响应于在当前滑动时间窗内，所述故障告警的数量大于预设数量，自动触发根因定位指令。
在一个实施例中，提供了一种计算机设备，该计算机设备根据所要应用的程序逻辑，具体可以是一种电子设备，也可以是一种服务器，其内部结构图可以如图10所示。该计算机设备包括通过***总线连接的处理器、存储器、通信接口、显示屏和输入装置。
其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作***和计算机程序。该内存储器为非易失性存储介质中的操作***和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、移动蜂窝网络、NFC(近场通信)或其他技术实现。
其中，该计算机程序被执行时以实现一种根因定位方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。
本领域技术人员可以理解，图10中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备(包括服务器和电子设备)的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被执行时实现以下步骤：
响应运维***触发根因定位指令，确定在当前时间窗口内所述运维***响应的多个服务节点；其中，在各所述服务节点中分别包括有至少一个服务请求，所述运维***用于执行所述至少一个服务请求，以实现所述服务节点对应的服务功能；
获取所述运维***在分别执行各所述服务节点的服务请求时，对应产生的运维数据；
基于所述运维数据，分别对各所述服务节点进行根因评价，得到针对各所述服务节点的评价结果；所述根因评价用于评价由所述服务节点导致所述运维***出现***异常的可能性程度；
基于所述评价结果，从所述多个服务节点中确定出根因节点；
其中，所述根因节点为导致所述运维***出现***异常，以触发所述根因定位指令的异常服务节点。
在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：
响应运维***触发根因定位指令，确定在当前时间窗口内所述运维***响应的多个服务节点；其中，在各所述服务节点中分别包括有至少一个服务请求，所述运维***用于执行所述至少一个服务请求，以实现所述服务节点对应的服务功能；
获取所述运维***在分别执行各所述服务节点的服务请求时，对应产生的运维数据；
基于所述运维数据，分别对各所述服务节点进行根因评价，得到针对各所述服务节点的评价结果；所述根因评价用于评价由所述服务节点导致所述运维***出现***异常的可能性程度；
基于所述评价结果，从所述多个服务节点中确定出根因节点；
其中，所述根因节点为导致所述运维***出现***异常，以触发所述根因定位指令的异常服务节点。
需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据。
本领域内的技术人员应明白，本申请的实施例可提供有根因定位方法、根因定位装置、服务器、计算机设备、计算机可读存储介质或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机程序指令(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例中根因定位方法、根因定位装置、服务器、计算机设备、计算机可读存储介质或计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序产品实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序产品到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的程序指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序产品也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机程序产品中的程序指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的程序指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。
Claims (12)
1.一种根因定位方法，其特征在于，所述方法包括：
响应运维***触发根因定位指令，确定在当前时间窗口内所述运维***响应的多个服务节点；其中，在各所述服务节点中分别包括有至少一个服务请求，所述运维***用于执行所述至少一个服务请求，以实现所述服务节点对应的服务功能；
获取所述运维***在分别执行各所述服务节点的服务请求时，对应产生的运维数据；
基于所述运维数据，分别对各所述服务节点进行根因评价，得到针对各所述服务节点的评价结果；所述根因评价用于评价由所述服务节点导致所述运维***出现***异常的可能性程度；
基于所述评价结果，从所述多个服务节点中确定出根因节点；
其中，所述根因节点为导致所述运维***出现***异常，以触发所述根因定位指令的异常服务节点。
2.根据权利要求1所述的方法，其特征在于，所述基于所述运维数据，分别对各所述服务节点进行根因评价，得到针对各所述服务节点的评价结果，包括：
基于所述运维数据，确定所述运维***在分别响应各所述服务节点时的性能指标和功能指标；所述性能指标用于表征所述运维***在响应服务节点时的***性能状况，所述功能指标用于表征所述运维***在响应服务节点时所应用的功能服务状况；
基于预设的分数因子，对各所述服务节点的性能指标进行第一评分，得到针对所述性能指标的第一评价分数；以及
基于预设的权重因子，对各所述服务节点的功能指标进行第二评分，得到针对所述功能指标的第二评价分数；
基于所述第一评价分数和所述第二评价分数，确定针对各所述服务节点的评价结果。
3.根据权利要求2所述的方法，其特征在于，所述性能指标表征有对应的指标值；
在确定所述运维***在分别响应各所述服务节点时的性能指标之后，还包括：
获取所述运维***在历史时间窗口内响应的历史服务节点的历史性能指标的历史指标值；所述历史时间窗口包括所述当前时间窗口；
将所述历史性能指标的历史指标值输入预训练的指标预测模型中进行安全性能预测，得到预测的安全性能区间；
基于所述当前时间窗口内的各所述服务节点的性能指标的指标值与所述安全性能区间之间的大小关系，确定各所述服务节点的性能指标的实时状态。
4.根据权利要求3所述的方法，其特征在于，所述基于所述当前时间窗口内的各所述服务节点的性能指标的指标值与所述安全性能区间之间的大小关系，确定各所述服务节点的性能指标的实时状态，包括以下两项：
在预设时间长度内，若所述服务节点的性能指标的指标值均处于所述安全性能区间内，则确定所述服务节点的性能指标在所述预设时间长度内的实时状态为正常状态；
在预设时间长度内，若所述服务节点的性能指标的指标值均未处于所述安全性能区间内，则确定所述服务节点的性能指标在所述预设时间长度内的实时状态为异常状态。
5.根据权利要求3所述的方法，其特征在于，所述基于预设的分数因子，对各所述服务节点的性能指标进行第一评分，得到针对所述性能指标的第一评价分数，包括：
将对应所述实时状态的性能指标的分数因子作为针对所述性能指标的第一评价分数；
其中，不同所述实时状态的性能指标对应预设有不同的分数因子。
6.根据权利要求2所述的方法，其特征在于，所述功能指标表征有对应的指标值；
所述基于预设的权重因子，对各所述服务节点的功能指标进行第二评分，得到针对所述功能指标的第二评价分数，包括：
将所述功能指标的指标值与对应权重因子之间的乘积值作为针对所述性能指标的第一评价分数；
其中，不同的所述功能指标对应预设有不同的权重因子。
7.根据权利要求2所述的方法，其特征在于，所述性能指标至少包括所述运维***在响应服务节点时的P99耗时、日志错误率、请求失败率和数据故障率；所述功能指标至少包括所述运维***在响应服务节点时的应用人数比例、异常应用比例、对应产生变更类型的运维数据的数量；
所述基于所述第一评价分数和所述第二评价分数，确定针对各所述服务节点的评价结果，包括：
针对每一所述服务节点，确定各个性能指标的第一评价分数和将各个功能指标的第二评价分数之间的总分数，并将所述总分数作为所述服务节点的评价结果。
8.根据权利要求7所述的方法，其特征在于，所述基于所述评价结果，从所述多个服务节点中确定出根因节点，包括：
在各个所述服务节点，将对应所述总分数最高的目标服务节点作为根因节点。
9.根据权利要求1所述的方法，其特征在于，所述响应所述运维***触发根因定位指令，包括：
获取终端用户发起的故障告警；
响应于在当前滑动时间窗内，所述故障告警的数量大于预设数量，自动触发根因定位指令。
10.一种根因定位装置，其特征在于，包括：
指令触发单元，被配置为执行响应运维***触发根因定位指令，确定在当前时间窗口内所述运维***响应的多个服务节点；其中，在各所述服务节点中分别包括有至少一个服务请求，所述运维***用于执行所述至少一个服务请求，以实现所述服务节点对应的服务功能；
数据获取单元，被配置为执行获取所述运维***在分别执行各所述服务节点的服务请求时，对应产生的运维数据；
节点评价单元，被配置为执行基于所述运维数据，分别对各所述服务节点进行根因评价，得到针对各所述服务节点的评价结果；所述根因评价用于评价由所述服务节点导致所述运维***出现***异常的可能性程度；
节点筛选单元，基于所述评价结果，从所述多个服务节点中确定出根因节点；
其中，所述根因节点为导致所述运维***出现***异常，以触发所述根因定位指令的异常服务节点。
11.一种计算机设备，其特征在于，包括：
处理器；
用于存储所述处理器的可执行指令的存储器；
其中，所述处理器被配置为执行所述可执行指令，以实现如权利要求1至9中任一项所述的根因定位方法。
12.一种计算机可读存储介质，所述计算机可读存储介质中包括程序数据，其特征在于，当所述程序数据由计算机设备的处理器执行时，使得所述计算机设备能够执行如权利要求1至9中任一项所述的根因定位方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311213288.6A CN117194092A (zh) | 2023-09-19 | 2023-09-19 | 根因定位方法、根因定位装置、计算机设备及存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311213288.6A CN117194092A (zh) | 2023-09-19 | 2023-09-19 | 根因定位方法、根因定位装置、计算机设备及存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117194092A true CN117194092A (zh) | 2023-12-08 |
Family
ID=88988542
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311213288.6A Pending CN117194092A (zh) | 2023-09-19 | 2023-09-19 | 根因定位方法、根因定位装置、计算机设备及存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117194092A (zh) |
-
2023
- 2023-09-19 CN CN202311213288.6A patent/CN117194092A/zh active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2020259421A1 (zh) | 一种业务***的监控方法及装置 | |
| US11586972B2 (en) | Tool-specific alerting rules based on abnormal and normal patterns obtained from history logs | |
| CN110321371B (zh) | 日志数据异常检测方法、装置、终端及介质 | |
| US10467533B2 (en) | System and method for predicting response time of an enterprise system | |
| US9436535B2 (en) | Integration based anomaly detection service | |
| US11805005B2 (en) | Systems and methods for predictive assurance | |
| US9397906B2 (en) | Scalable framework for monitoring and managing network devices | |
| US11281522B2 (en) | Automated detection and classification of dynamic service outages | |
| US20200012990A1 (en) | Systems and methods of network-based intelligent cyber-security | |
| CN112308126A (zh) | 故障识别模型训练方法、故障识别方法、装置及电子设备 | |
| CN112631887A (zh) | 异常检测方法、装置、电子设备和计算机可读存储介质 | |
| Bogojeska et al. | Classifying server behavior and predicting impact of modernization actions | |
| US20230038164A1 (en) | Monitoring and alerting system backed by a machine learning engine | |
| US7617313B1 (en) | Metric transport and database load | |
| CN114202256A (zh) | 架构升级预警方法、装置、智能终端及可读存储介质 | |
| CN113722134A (zh) | 一种集群故障处理方法、装置、设备及可读存储介质 | |
| CN107480703B (zh) | 交易故障检测方法及装置 | |
| CN113254153A (zh) | 流程任务处理方法、装置、计算机设备和存储介质 | |
| CN110413482B (zh) | 检测方法和装置 | |
| CN112416896A (zh) | 数据异常的报警方法和装置、存储介质、电子装置 | |
| CN117194092A (zh) | 根因定位方法、根因定位装置、计算机设备及存储介质 | |
| CN114676021A (zh) | 作业日志监控方法、装置、计算机设备和存储介质 | |
| CN115098326A (zh) | 一种***异常检测方法及装置、存储介质及电子设备 | |
| CN112764957A (zh) | 应用故障定界方法及装置 | |
| Watanabe et al. | Failure prediction for cloud datacenter by hybrid message pattern learning |
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 |