CN112559300B - 一种故障原因确定系统、方法及装置 - Google Patents

一种故障原因确定系统、方法及装置 Download PDF

Info

Publication number
CN112559300B
CN112559300B CN202011465772.4A CN202011465772A CN112559300B CN 112559300 B CN112559300 B CN 112559300B CN 202011465772 A CN202011465772 A CN 202011465772A CN 112559300 B CN112559300 B CN 112559300B
Authority
CN
China
Prior art keywords
abnormal
transaction
condition
information
target server
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.)
Active
Application number
CN202011465772.4A
Other languages
English (en)
Other versions
CN112559300A (zh
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.)
Industrial and Commercial Bank of China Ltd ICBC
Original Assignee
Industrial and Commercial Bank of China Ltd ICBC
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 Industrial and Commercial Bank of China Ltd ICBC filed Critical Industrial and Commercial Bank of China Ltd ICBC
Priority to CN202011465772.4A priority Critical patent/CN112559300B/zh
Publication of CN112559300A publication Critical patent/CN112559300A/zh
Application granted granted Critical
Publication of CN112559300B publication Critical patent/CN112559300B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/32Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/324Display of status information
    • G06F11/327Alarm or error message display
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3051Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • G06F11/3476Data logging

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本说明书实施例提供一种故障原因确定系统、方法及装置,可以应用于人工智能技术领域。所述方法包括:接收多个服务器节点的日志信息;获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因,从而提高故障原因的确定效率。

Description

一种故障原因确定系统、方法及装置
技术领域
本说明书实施例涉及人工智能技术领域,特别涉及一种故障原因确定系统、方法及装置。
背景技术
随着互联网技术和人工智能技术的发展,通过英特网进行在线交易越来越普及,人们除了可以通过现金交易和POS机刷卡交易,还可以通过手机端的各类可支付软件(第三方支付软件、银行支付软件等)进行在线交易,通过这些在线交易,资金将从付款方转移至收款方。在线交易过程中,若承担交易过程中的资金转移功能的系统存在异常将导致支付不成功,需要及时的进行处理,以恢复系统的正常功能。
现有技术中,对系统进行运维的方法,通常是在系统出现异常时,由运维人员检查原因并进行修复。为保证系统可用率无限接近100%,对故障的发现、止损、修复和规避。发生了什么、怎么解决、多长时间能解决,这些都是运维人员在处理突发故障时主要关心的问题。为减少人力成本,目前出现了自动化运维的方式,可以设置监控系统和报警系统。监控系统可以对系统的数据进行监控,若出现异常数据,则由报警系统产生报警信息,再由运维人员根据产生的异常数据和报警信息对故障进行分析和处理。
但是,在当今虚拟化和服务化的大背景下,分布式系统部署少则几十个,多则成百上千的节点,这就意味着当某一节点出现故障时,各类将反映出多个业务类型报警、业务成功率报警、系统报警等输出十分混乱,干扰运维人员的故障排摸方向,使得运维生产问题排查难度直线上升。而随着快捷支付业务的普及,快捷支付业务已逐渐成为民生领域主要的支付手段之一。快捷系统的异常波动,直接影响客户的用户体验,需时刻保障快捷支付系统的稳定性和系统异常情况下运维的快速响应能力。
基于传统运维的监控和报警系统存在一定缺陷,大量的监控报警极大的分散了运维人员的注意力,消耗大量的时间和精力,使得对于故障原因的确定效率不高。
发明内容
本说明书实施例的目的是提供一种故障原因确定系统、方法及装置,以提高故障原因的确定效率。
为解决上述问题,本说明书实施例提供一种故障原因确定系统,所述系统包括日志采集平台和日志分析平台;所述日志采集平台,用于采集多个服务器节点的日志信息,将所述日志信息提供给所述日志分析平台;所述日志分析平台,用于获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志采集平台提供的日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。
为解决上述问题,本说明书实施例还提供一种故障原因确定方法,所述方法包括:接收多个服务器节点的日志信息;获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。
为解决上述问题,本说明书实施例还提供一种故障原因确定装置,所述装置包括:接收模块,用于接收多个服务器节点的日志信息;获取模块,用于获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;计算模块,用于根据所述日志信息计算交易处理过程中的指标信息;确定模块,用于在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;分析模块,用于基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。
为解决上述问题,本说明书实施例还提供一种电子设备,包括:存储器,用于存储计算机程序;处理器,用于执行所述计算机程序以实现:接收多个服务器节点的日志信息;获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。
为解决上述问题,本说明书实施例还提供一种计算机可读存储介质,其上存储有计算机指令,所述指令被执行时实现:接收多个服务器节点的日志信息;获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。
由以上本说明书实施例提供的技术方案可见,本说明书实施例中,可以接收多个服务器节点的日志信息;获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。本说明书实施例提供的方法,与现有技术相比,不需要,运维人员逐个服务去确认交易日志,可以对日志数据汇总归集分析,提高运维人员问题分析效率,减少人工运维成本,提高故障原因的确定效率,进而提高应用系统的应急处理时效。
附图说明
为了更清楚地说明本说明书实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本说明书中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本说明书实施例快捷支付系统的系统结构示意图;
图2为本说明书实施例快捷支付系统非服务化部署结构示意图;
图3为本说明书实施例快捷支付系统服务化部署结构示意图;
图4为本说明书实施例一种故障原因确定系统的结构示意图;
图5为本说明书实施例故障原因分析过程示意图;
图6为本说明书实施例一种故障原因确定方法的流程图;
图7为本说明书实施例一种电子设备的功能结构示意图;
图8为本说明书实施例一种故障原因确定装置的功能结构示意图。
具体实施方式
下面将结合本说明书实施例中的附图,对本说明书实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本说明书一部分实施例,而不是全部的实施例。基于本说明书中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本说明书保护的范围。
快捷支付指用户购买商品时,不需开通网银,只需提供银行卡卡号、户名、手机号码等信息,银行验证手机号码正确性后,第三方支付发送手机动态口令到用户手机号上,用户输入正确的手机动态口令,即可完成支付。如果用户选择保存卡信息,则用户下次支付时,只需输入第三方支付的支付密码或者是支付密码及手机动态口令即可完成支付。
第三方快捷支付系统主要负责与网联对接,接受支付机构发起的扣划客户账户资金的指令,完成交易资金划转,包括客户签约、支付、退货、提现等交易。
图1为快捷支付系统的系统结构示意图,第三方快捷支付系统可以由服务化集群和非服务化集群两部分组成。非服务化集群负责支付类相关业务,服务化集群负责非支付类(签约、退货、提现等)相关业务。网联将第三方支付机构的交易请求发送给银行的软负载服务器,软负载根据包括交易请求的报文中的交易类型,将交易请求分发至服务化集群或非服务化集群进行交易处理。在涉及账务处理部分,所有交易均可直接上送核心主机进行处理,个人借记卡动账现主要由平台个人结算账户处理,在应急情况下可进行切换。
图2和图3分别为快捷支付系统非服务化与服务化详细部署结构。支付机构数据库均可以按尾号独立部署,其中奇数库和偶数库分别部署在两个园区,且按一定规则互为备份可接管交易。非服务化集群和服务化集群与数据库成串行结构,例如,一个支付机构按照尾号划分为10个集群,每个集群只访问其对应的数据库,无交叉访问关系。非服务化尾号集群进行单园区部署,通过应用自身接管能力及软负载扎策略实现双园区高可用;服务化尾号集群为双园区部署,一个尾号在两个园区均有服务部署。
随着快捷支付业务的普及,快捷支付业务已逐渐成为民生领域主要的支付手段之一,因此在线交易过程中,若承担交易过程中的资金转移功能的系统存在异常将导致支付不成功,需要及时的进行处理,以恢复系统的正常功能。针对第三方快捷支付系统运维的核心在于保障系统运行稳定,确保系统可以7×24小时对外服务,使系统的可用率无限接近100%。
目前运维在自动化方面已经达到了一定的水平,但在监控的聚合,分析判断方面还相当的薄弱,尤其是在当今虚拟化和服务化的大背景下,分布式系统部署少则几十个,多则成百上千的节点,这就意味着当某一节点出现故障时,将反映出多个业务类型报警、业务成功率报警、系统报警等,干扰运维人员的故障排摸方向,使得运维生产问题排查难度直线上升。基于传统运维的监控和报警系统存在一定缺陷,大量的监控报警极大的分散了运维人员的注意力,消耗大量的时间和精力,需要一个高效的方法让运维人员送纷繁复杂的报警中解脱出来,创造更多的生产价值。
考虑到如果通过对各类日志、报警信息的归类聚合分析以智能化的方式识别和迅速定位根因定位,协助快速解决问题,自动匹配预设故障场景并处理,则有望解决现有技术中需要运维人员逐个服务去确认交易日志导致的效率低下的问题,减少人工运维成本,提高故障原因的分析效率,进而提高应用系统的应急处理时效。基于此,本说明书实施例提供了一种故障原因确定系统、方法及装置
请参阅图4,本说明书提供了一种故障原因确定系统。所述故障原因确定系统可以包括日志采集平台410和日志分析平台420。
在一些实施例中,所述日志采集平台410可以用于采集多个服务器节点的日志信息,将所述日志信息提供给所述日志分析平台。
在一些实施例中,所述日志采集平台410可以为一个具有运算和网络交互功能的电子设备,例如可以为服务器;也可以为运行于该电子设备中,为数据处理和网络交互提供支持的软体。
在一些实施例中,所述日志采集平台410并不具体限定服务器的数量。所述日志采集平台410可以为一个服务器,还可以为几个服务器,或者,若干服务器形成的服务器集群。
在一些实施例中,所述日志采集平台410可以与各机构(支付宝、微信、财付通等)的非服务化支付集群、服务化支付集群,网联服务化支付集群,银行服务化支付集群等进行通信连接,并采集这些服务器集群的日志信息。
日志可以为网络设备、系统及服务程序等,在运作时都会产生一个叫log的事件记录;每一行日志都记载着日期、时间、使用者及动作等相关操作的描述。Windows网络操作系统都设计有各种各样的日志文件,如应用程序日志信息,安全日志、系统日志、Scheduler服务日志、FTP日志、WWW日志、DNS服务器日志等等,这些根据系统开启的服务的不同而有所不同,在系统上进行一些操作时,这些日志文件通常会记录下用户操作的一些相关内容。
所述日志采集平台410可以汇总记录各个服务器节点发送的日志信息,并进行集中存储。所述日志信息中包括事件记录和服务器节点的IP等信息。所述事件记录可以包业务返回码、交易耗时、调用关系等明细数据。
在一些实施例中,所述日志采集平台410还可以与CMDB系统建立通信连接。所述CMDB系统包括配置管理数据库(Configuration Management Database,CMDB)。所述配置管理数据库为一个逻辑数据库,包含了配置项全生命周期的信息以及配置项之间的关系(包括物理关系、实时通信关系、非实时通信关系和依赖关系等)。配置管理数据库可以由几个物理数据库组成,这些数据库形成了一个逻辑实体,对数据库之间的整合状况要进行优化,所有配置项信息都包括在配置管理数据库中。配置管理数据库对所有的IT组件、组件的不同版本和状态,以及组件之间的关系进行跟踪。
所述日志采集平台410可以从CMDB系统中定时获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点。例如可以获取包括与所述日志采集平台410建立通信连接的各机构(支付宝、微信、财付通等)的非服务化支付集群、服务化支付集群,网联服务化支付集群等服务器集群中各个服务器节点的配置信息。其中,所述配置信息可以包括服务器类型、服务器节点所属集群、IP地址、物理设备信息、机房信息等。
在一些实施例中,所述日志分析平台420可以用于获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志采集平台提供的日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。
在一些实施例中,所述日志分析平台420可以为一个具有运算和网络交互功能的电子设备,例如可以为服务器;也可以为运行于该电子设备中,为数据处理和网络交互提供支持的软体。
在一些实施例中,所述日志分析平台420并不具体限定服务器的数量。所述日志分析平台420可以为一个服务器,还可以为几个服务器,或者,若干服务器形成的服务器集群。
在一些实施例中,所述日志分析平台420可以与所述日志采集平台410建立通信连接,并从所述日志采集平台410中获取配置列表和日志信息。所述日志分析平台420还可以与CMDB系统建立通信连接,从CMDB系统中获取配置列表。
在一些实施例中,所述指标信息可以包括多个指标值。所述指标值可以包括交易率、成功率、响应时间、异常返回占比等。所述日志分析平台420可以根据所述日志采集平台提供的日志信息计算交易处理过程中的指标信息。举例来说,所述日志分析平台420可以根据日志信息中交易耗时计算交易的响应时间,根据日志信息中的业务返回码判断业务是否正常执行,进而计算交易率、成功率、异常返回占比等指标值。
在一些实施例中,所述日志分析平台420还可以基于交易的类型,分别计算交易处理过程中支付类交易的指标信息和非支付类交易的指标信息,从而可以根据不同交易类型的指标信息来判断故障原因。其中,所述支付类交易为与支付相关的交易;所述非支付交易为与支付不相关的交易,例如签约、退货、提现等交易。
在一些实施例中,所述日志分析平台420可以根据以下方式确定所述指标信息出现异常:分别判断所述指标信息中的指标值是否处于预设区间;其中,不同的指标值对应有不同的预设区间;在所述指标信息中至少一个指标值处于预设区间的情况下,确定所述指标信息出现异常;否则确定所述指标信息未出现异常。举例来说,交易率对应的预设区间为[0,60%],若交易率处于该区间内,则可以确定所述指标信息出现异常;异常返回占比对应的预设区间为[50%,100%],若异常返回占比处于该区间内,则可以确定所述指标信息出现异常。当然,两种或者两种以上不同的指标值都处于对应的预设区间内,也可以确定所述指标信息出现异常;当所述指标信息中的指标值都不处于对应的预设区间,则可以确定所述指标信息未出现异常。
在一些实施例中,在所述指标信息出现异常的情况下,所述日志分析平台420可以基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点。具体的,由于日志信息中包括服务器节点的IP,因此可以基于日志信息中的服务器节点的IP,可以确定出异常的指标信息对应的服务器IP,再结合服务器列表中服务器节点的配置信息,例如服务器列表中服务器节点的IP,服务器节点所属集群等信息确定出现异常的目标服务器节点,也可以结合服务器列表中服务器节点的物理设备信息、机房信息等确定具体出现异常的是哪一个服务器设备。
在一些实施例中,所述交易情况可以包括指标信息的波动情况,银行卡的交易是否出现异常等。具体的,若出现异常的服务器节点为非服务化支付节点,则可以基于非服务化节点对应的指标信息确定非支付类交易的指标信息波动情况。例如预设时间内某个指标值上下波动超过预设值,例如为10%,则可以确定非支付类交易的指标信息出现了明显波动,若小于10%则可以确定为未出现明显波动。当然,这里的预设值也可以设置为其他数值,例如为5%、15%等数值,不同指标值对应的预设值可以相同也可以不同。同样的,若出现异常的服务器节点为服务化支付节点,可以基于服务化节点对应的指标信息确定支付类交易的指标信息波动情况,具体过程与确定非支付类交易的指标信息波动情况相类似。
若出现异常的服务器节点为银行的行内接入节点,还可以确定银行卡的交易是否出现异常。具体的,可以分别确定借记卡、贷记卡的交易是否出现异常。例如,预设时间内借记卡对应的指标值如响应时间变长,成功率下降等,则可以确定借记卡出现异常。类似的,也可以确定贷记卡的交易是否出现异常。
在一些实施例中,所述日志分析平台420还可以基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。具体的,如图5所示,所述日志分析平台420的分析过程可以包括以下步骤。
S1:在异常数据产生时,可以判断服务器设备是否一致。
具体的,可以基于出现异常的目标服务器节点的配置信息,如IP地址、物理设备信息、机房信息等判断出现异常的服务器节点是否为同一底层设备。若是,则可以确定故障原因为设备系统出现异常;否则进入步骤S2。
S2:判断所属集群是否一致。
具体的,可以基于异常的目标服务器节点的配置信息,如所属集群判断出现异常的目标服务器节点是否属于同一支付机构集群,如支付宝、财付通或娶她机构。其中,接入层如网联接入节点、银行的行内接入节点等作为各个机构的共用集群,在判断中不将共用集群与其他机构集群判断为同属一个集群。若异常的目标服务器节点属于同一支付机构集群,则进入S3;否则进入S6。
S3:判断交易情况是否异常。
具体的,可以根据指标信息的波动情况判断交易情况是否异常。举例来说,若预设时间内某个指标值上下波动超过预设值,例如为10%,则可以确定指标信息出现了明显波动,判断交易情况异常;若小于10%则可以确定为未出现明显波动,判断交易未出现异常。当然,这里的预设值也可以设置为其他数值,例如为5%、15%等数值,不同指标值对应的预设值可以相同也可以不同。若交易情况出现异常,则可以未出现异常,则可以确定故障原因为接入层节点异常,这里的接入层节点可以包括网联接入节点和银行的行内接入节点;否则进入S4。
S4:判断支付类交易是否异常。
具体的,可以根据支付类交易的指标信息波动情况来判断支付类交易是否异常。若支付类交易的指标信息出现了明显波动,可以确定支付类交易出现异常;否则支付类交易未出现异常。若支付类交易出现异常,则可以确定故障原因为服务化支付节点异常;否则进入S5。
S5:判断非支付类交易是否异常。
具体的,可以根据支付类交易的指标信息波动情况来判断非支付类交易是否异常。若非支付类交易的指标信息出现了明显波动,可以确定非支付类交易出现异常;否则非支付类交易未出现异常。若非支付类交易出现异常,则可以确定故障原因为非服务化支付节点异常;否则进入确定故障原因为单台数据库异常。
S6:判断贷记卡交易是否正常。
具体的,可以根据预设时间内借记卡对应的指标值的波动情况判断贷记卡交易是否正常。若贷记卡交易的响应时间变长,成功率下降等,则可以确定贷记卡交易出现异常;否则确定贷记卡交易正常。若贷记卡交易正常,则进入S7;否则可以确定故障原因为平台个人结算账户系统异常。
S7:判断接入层是否异常。
具体的,可以根据S3的判断确定接入层是否异常。若接入层异常,则可以确定故障原因为网络故障;否则确定故障原因为核心主机异常。
当然,由于故障的类型和原因多种多样,还可能出现上述场景无法判断的情况,如果出现单场景无法匹配情况,则优先考虑为多场景同时发生,程序进行多场景匹配,先匹配严重程度高场景,再匹配严重程度底场景,同时触发多条报警;如程序无法进行判断,则产生未识别异常的报警信息,通知一线值班联系运维人员人工应急,确认故障场景,并在应急完成后对故障场景进行补充优化。
在一些实施例中,所述日志分析平台420还可以与应用监控系统建立通信连接。所述应用监控系统可以接收日志分析平台420针对故障原因的分析结果,并生成报警信息。例如可以以可视化的方式显示出现异常的服务器节点,以便于工作人员能够及时观察到出现异常的服务器节点。
在一些实施例中,所述日志分析平台420还可以将分析结果以短信或者邮件的方式通知工作人员,以便于工作人员针对故障原因作出相应的处理,提高对故障的处理效率。
在一些实施例中,所述故障原因确定系统还可以包括应急处理平台430。所述应急处理平台可以基于所述日志分析平台420的分析结果从数据库中查找所述故障原因对应的处理策略,以便于根据所述处理策略对故障进行修复。表1示例性的给出了故障原因对应的处理策略。
表1
在一些实施例中,从数据库中查找所述故障原因对应的处理策略包括:可以预先将故障原因与所述故障原因对应的处理策略关联存储至数据库中,从而可以从数据库中查找所述故障原因对应的处理策略。举例来说,可以通过数据表的方式关联存储故障原因与所述故障原因对应的处理策略,数据表的一列存储故障原因,另一列存储对应的处理策略,具有关联关系的故障原因和处理策略处于同一行。当然,从数据库中查找所述故障原因对应的处理策略不限于上述列举的方式,所述领域技术人员在本说明书实施例的启示下,还可能做出其它变更,但只要其实现的功能和效果与本说明书实施例相同或相似,均应涵盖与本说明书实施例保护的范围内。
由以上本说明书实施例提供的技术方案可见,本说明书实施例中,可以接收多个服务器节点的日志信息;获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。本说明书实施例提供的方法,与现有技术相比,不需要,运维人员逐个服务去确认交易日志,可以对日志数据汇总归集分析,提高运维人员问题分析效率,减少人工运维成本,提高故障原因的确定效率,进而提高应用系统的应急处理时效。
请参阅图6。本说明实施例还提供一种故障原因确定方法。在本说明书实施例中,执行所述故障原因确定方法的主体可以是具有逻辑运算功能的电子设备,所述电子设备可以是服务器。所述服务器可以是具有一定运算处理能力的电子设备。其可以具有网络通信单元、处理器和存储器等。当然,所述服务器并不限于上述具有一定实体的电子设备,其还可以为运行于上述电子设备中的软体。所述服务器还可以为分布式服务器,可以是具有多个处理器、存储器、网络通信模块等协同运作的系统。或者,服务器还可以为若干服务器形成的服务器集群。所述方法可以包括以下步骤。
S610:接收多个服务器节点的日志信息。
在一些实施例中,所述多个服务器节点可以为各机构(支付宝、微信、财付通等)的非服务化支付集群、服务化支付集群,网联服务化支付集群,银行服务化支付集群等集群的节点。所述服务器可以与这些服务器集群建立通信连接,并采集这些服务器集群中各个服务器节点的日志信息。所述服务器可以汇总记录各个服务器节点发送的日志信息,并进行集中存储。所述日志信息中包括事件记录和服务器节点的IP等信息。所述事件记录可以包业务返回码、交易耗时、调用关系等明细数据。
S620:获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点。
在一些实施例中,服务器可以获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点。例如可以获取包括与所述日志采集平台410建立通信连接的各机构(支付宝、微信、财付通等)的非服务化支付集群、服务化支付集群,网联服务化支付集群等服务器集群中各个服务器节点的配置信息。其中,所述配置信息可以包括服务器类型、服务器节点所属集群、IP地址、物理设备信息、机房信息等。通过这些配置信息可以确定各个服务器节点的特征,以便于提高对故障原因的分析效率。
S630:根据所述日志信息计算交易处理过程中的指标信息。
在一些实施例中,所述交易可以包括支付类交易和非支付类交易。所述服务器还可以基于交易的类型,分别计算交易处理过程中支付类交易的指标信息和非支付类交易的指标信息,从而可以根据不同交易类型的指标信息来判断故障原因。其中,所述支付类交易为与支付相关的交易;所述非支付交易为与支付不相关的交易,例如签约、退货、提现等交易。分别对不同交易类型的指标信息进行分析,可以提高故障分析的准确性。
在一些实施例中,所述指标信息可以包括多个指标值。所述指标值可以包括交易率、成功率、响应时间、异常返回占比等。所述服务器可以根据所述日志信息计算交易处理过程中的指标信息。举例来说,所述服务器可以根据日志信息中交易耗时计算交易的响应时间,根据日志信息中的业务返回码判断业务是否正常执行,进而计算交易率、成功率、异常返回占比等指标值。这些指标值能够准确反映服务器节点的运行状态,可以根据这些指标值来确定服务器节点的运行状态是否正常,进而能够提高故障分析的准确性。
S640:在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点。
在一些实施例中,所述服务器可以根据以下方式确定所述指标信息出现异常:分别判断所述指标信息中的指标值是否处于预设区间;其中,不同的指标值对应有不同的预设区间;在所述指标信息中至少一个指标值处于预设区间的情况下,确定所述指标信息出现异常。举例来说,交易率对应的预设区间为[0,60%],若交易率处于该区间内,则可以确定所述指标信息出现异常;异常返回占比对应的预设区间为[50%,100%],若异常返回占比处于该区间内,则可以确定所述指标信息出现异常。当然,两种或者两种以上不同的指标值都处于对应的预设区间内,也可以确定所述指标信息出现异常;当所述指标信息中的指标值都不处于对应的预设区间,则可以确定所述指标信息未出现异常。通过这种方式可以准确地判断指标信息是否出现异常。
在一些实施例中,在所述指标信息出现异常的情况下,所述服务器可以基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点。具体的,由于日志信息中包括服务器节点的IP,因此可以基于日志信息中的服务器节点的IP,可以确定出异常的指标信息对应的服务器IP,再结合服务器列表中服务器节点的配置信息,例如服务器列表中服务器节点的IP,服务器节点所属集群等信息确定出现异常的目标服务器节点,也可以结合服务器列表中服务器节点的物理设备信息、机房信息等确定具体出现异常的是哪一个服务器设备。
在一些实施例中,所述交易情况可以包括指标信息的波动情况,银行卡的交易是否出现异常等。具体的,若出现异常的服务器节点为非服务化支付节点,则可以基于非服务化节点对应的指标信息确定非支付类交易的指标信息波动情况。例如预设时间内某个指标值上下波动超过预设值,例如为10%,则可以确定非支付类交易的指标信息出现了明显波动,若小于10%则可以确定为未出现明显波动。当然,这里的预设值也可以设置为其他数值,例如为5%、15%等数值,不同指标值对应的预设值可以相同也可以不同。同样的,若出现异常的服务器节点为服务化支付节点,可以基于服务化节点对应的指标信息确定支付类交易的指标信息波动情况,具体过程与确定非支付类交易的指标信息波动情况相类似。通过对交易情况的确定,可以了解各个服务器节点的整体运行情况,进而能够通过交易情况来对故障原因进行分析。
若出现异常的服务器节点为银行的行内接入节点,还可以确定银行卡的交易是否出现异常。具体的,可以分别确定借记卡、贷记卡的交易是否出现异常。例如,预设时间内借记卡对应的指标值如响应时间变长,成功率下降等,则可以确定借记卡出现异常。类似的,也可以确定贷记卡的交易是否出现异常。
S650:基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。
在一些实施例中,所述服务器还可以基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。具体的,如图5所示,所述服务器的分析过程可以包括以下步骤。
S1:在异常数据产生时,可以判断服务器设备是否一致。
具体的,可以基于出现异常的目标服务器节点的配置信息,如IP地址、物理设备信息、机房信息等判断出现异常的服务器节点是否为同一底层设备。若是,则可以确定故障原因为设备系统出现异常;否则进入步骤S2。
S2:判断所属集群是否一致。
具体的,可以基于异常的目标服务器节点的配置信息,如所属集群判断出现异常的目标服务器节点是否属于同一支付机构集群,如支付宝、财付通或娶她机构。其中,接入层如网联接入节点、银行的行内接入节点等作为各个机构的共用集群,在判断中不将共用集群与其他机构集群判断为同属一个集群。若异常的目标服务器节点属于同一支付机构集群,则进入S3;否则进入S6。
S3:判断交易情况是否异常。
具体的,可以根据指标信息的波动情况判断交易情况是否异常。举例来说,若预设时间内某个指标值上下波动超过预设值,例如为10%,则可以确定指标信息出现了明显波动,判断交易情况异常;若小于10%则可以确定为未出现明显波动,判断交易未出现异常。当然,这里的预设值也可以设置为其他数值,例如为5%、15%等数值,不同指标值对应的预设值可以相同也可以不同。若交易情况出现异常,则可以未出现异常,则可以确定故障原因为接入层节点异常,这里的接入层节点可以包括网联接入节点和银行的行内接入节点;否则进入S4。
S4:判断支付类交易是否异常。
具体的,可以根据支付类交易的指标信息波动情况来判断支付类交易是否异常。若支付类交易的指标信息出现了明显波动,可以确定支付类交易出现异常;否则支付类交易未出现异常。若支付类交易出现异常,则可以确定故障原因为服务化支付节点异常;否则进入S5。
S5:判断非支付类交易是否异常。
具体的,可以根据支付类交易的指标信息波动情况来判断非支付类交易是否异常。若非支付类交易的指标信息出现了明显波动,可以确定非支付类交易出现异常;否则非支付类交易未出现异常。若非支付类交易出现异常,则可以确定故障原因为非服务化支付节点异常;否则进入确定故障原因为单台数据库异常。
S6:判断贷记卡交易是否正常。
具体的,可以根据预设时间内借记卡对应的指标值的波动情况判断贷记卡交易是否正常。若贷记卡交易的响应时间变长,成功率下降等,则可以确定贷记卡交易出现异常;否则确定贷记卡交易正常。若贷记卡交易正常,则进入S7;否则可以确定故障原因为平台个人结算账户系统异常。
S7:判断接入层是否异常。
具体的,可以根据S3的判断确定接入层是否异常。若接入层异常,则可以确定故障原因为网络故障;否则确定故障原因为核心主机异常。
当然,由于故障的类型和原因多种多样,还可能出现上述场景无法判断的情况,如果出现单场景无法匹配情况,则优先考虑为多场景同时发生,程序进行多场景匹配,先匹配严重程度高场景,再匹配严重程度底场景,同时触发多条报警;如程序无法进行判断,则产生未识别异常的报警信息,通知一线值班联系运维人员人工应急,确认故障场景,并在应急完成后对故障场景进行补充优化。
在一些实施例中,所述服务器还可以基于故障原因的分析结果,并生成报警信息。例如可以以可视化的方式显示出现异常的服务器节点,以便于工作人员能够及时观察到出现异常的服务器节点。
在一些实施例中,所述服务器还可以将分析结果以短信或者邮件的方式通知工作人员,以便于工作人员针对故障原因作出相应的处理,提高对故障的处理效率。
在一些实施例中,所述服务器还可以从数据库中查找所述故障原因对应的处理策略,以便于根据所述处理策略对故障进行修复,从而使得面对突发的异常事件,可以快速响应,迅速了解系统故障情况,并及时应急处理。具体的,可以预先将故障原因与所述故障原因对应的处理策略关联存储至数据库中,从而可以从数据库中查找所述故障原因对应的处理策略。举例来说,可以通过数据表的方式关联存储故障原因与所述故障原因对应的处理策略,数据表的一列存储故障原因,另一列存储对应的处理策略,具有关联关系的故障原因和处理策略处于同一行。当然,从数据库中查找所述故障原因对应的处理策略不限于上述列举的方式,所述领域技术人员在本说明书实施例的启示下,还可能做出其它变更,但只要其实现的功能和效果与本说明书实施例相同或相似,均应涵盖与本说明书实施例保护的范围内。
由以上本说明书实施例提供的技术方案可见,本说明书实施例中,可以接收多个服务器节点的日志信息;获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。本说明书实施例提供的方法,与现有技术相比,不需要,运维人员逐个服务去确认交易日志,可以对日志数据汇总归集分析,提高运维人员问题分析效率,减少人工运维成本,提高故障原因的确定效率,进而提高应用系统的应急处理时效。
图7为本说明书实施例一种电子设备的功能结构示意图,所述电子设备可以包括存储器和处理器。
在一些实施例中,所述存储器可用于存储所述计算机程序和/或模块,所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块,以及调用存储在存储器内的数据,实现故障原因确定方法的各种功能。所述存储器可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序;存储数据区可存储根据用户终端的使用所创建的数据。此外,存储器可以包括高速随机存取存储器,还可以包括非易失性存储器,例如硬盘、内存、插接式硬盘、智能存储卡(Smart Media Card,SMC)、安全数字(Secure Digital,SD)卡、闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
所述处理器可以是中央处理单元(Central Processing Unit,CPU),还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(APPlication Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable GateArray,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。所述处理器可以执行所述计算机指令实现以下步骤:接收多个服务器节点的日志信息;获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。
在本说明书实施例中,该电子设备具体实现的功能和效果,可以与其它实施例对照解释,在此不再赘述。
图8为本说明书实施例一种故障原因确定装置的功能结构示意图,该装置具体可以包括以下的结构模块。
接收模块810,用于接收多个服务器节点的日志信息;
获取模块820,用于获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;
计算模块830,用于根据所述日志信息计算交易处理过程中的指标信息;
获得模块840,用于在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;
确定模块850,用于基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。
本说明书实施例还提供了一种故障原因确定方法的计算机可读存储介质,所述计算机可读存储介质存储有计算机程序指令,在所述计算机程序指令被执行时实现:接收多个服务器节点的日志信息;获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因。
在本说明书实施例中,上述存储介质包括但不限于随机存取存储器(RandomAccess Memory,RAM)、只读存储器(Read-Only Memory,ROM)、缓存(Cache)、硬盘(HardDisk Drive,HDD)或者存储卡(Memory Card)。所述存储器可用于存储所述计算机程序和/或模块,所述存储器可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序等;存储数据区可存储根据用户终端的使用所创建的数据等。此外,存储器可以包括高速随机存取存储器,还可以包括非易失性存储器。在本说明书实施例中,该计算机可读存储介质存储的程序指令具体实现的功能和效果,可以与其它实施方式对照解释,在此不再赘述。
需要说明的是,本说明书实施例提供的故障原因确定系统、方法及装置,可以应用于人工智能技术领域。当然,也可以应用于金融领域,或者除金融领域之外的任意领域,本说明书实施例对所述故障原因确定系统、方法及装置的应用领域不做限定。
需要说明的是,本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同或相似的部分互相参见即可,每个实施例重点说明的都是与其它实施例的不同之处。尤其,对于装置实施例和设备实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本领域技术人员在阅读本说明书文件之后,可以无需创造性劳动想到将本说明书列举的部分或全部实施例进行任意组合,这些组合也在本说明书公开和保护的范围内。
在20世纪90年代,对于一个技术的改进可以很明显地区分是硬件上的改进(例如,对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而,随着技术的发展,当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此,不能说一个方法流程的改进就不能用硬件实体模块来实现。例如,可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray,FPGA))就是这样一种集成电路,其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上,而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且,如今,取代手工地制作集成电路芯片,这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现,它与程序开发撰写时所用的软件编译器相类似,而要编译之前的原始代码也得用特定的编程语言来撰写,此称之为硬件描述语言(Hardware Description Language,HDL),而HDL也并非仅有一种,而是有许多种,如ABEL(Advanced Boolean Expression Language)、AHDL(AlteraHardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等,目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog2。本领域技术人员也应该清楚,只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中,就可以很容易得到实现该逻辑方法流程的硬件电路。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
通过以上的实施方式的描述可知,本领域的技术人员可以清楚地了解到本说明书可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本说明书的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本说明书各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本说明书可用于众多通用或专用的计算机系统环境或配置中。例如:个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。
本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
虽然通过实施例描绘了本说明书,本领域普通技术人员知道,本说明书有许多变形和变化而不脱离本说明书的精神,希望所附的权利要求包括这些变形和变化而不脱离本说明书的精神。

Claims (12)

1.一种故障原因确定系统,其特征在于,所述系统包括日志采集平台和日志分析平台;
所述日志采集平台,用于采集多个服务器节点的日志信息,将所述日志信息提供给所述日志分析平台;
所述日志分析平台,用于获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志采集平台提供的日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因;其中,基于所述交易情况和所述目标服务器节点的配置信息确定故障原因,包括:判断出现异常的目标服务器节点是否属于同一个服务器设备;在判定出现异常的目标服务器节点属于同一个服务器设备的情况下,确定设备系统异常;在判定出现异常的目标服务器节点不属于同一个服务器设备的情况下,判断出现异常的目标服务器节点是否属于同一个服务器集群;在判定出现异常的目标服务器节点属于同一个服务器集群的情况下,判断交易情况是否异常;在判定交易情况不异常的情况下,确定接入层节点异常。
2.一种故障原因确定方法,其特征在于,所述方法包括:
接收多个服务器节点的日志信息;
获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;
根据所述日志信息计算交易处理过程中的指标信息;
在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;
基于所述交易情况和所述目标服务器节点的配置信息确定故障原因;
其中,基于所述交易情况和所述目标服务器节点的配置信息确定故障原因,包括:
判断出现异常的目标服务器节点是否属于同一个服务器设备;
在判定出现异常的目标服务器节点属于同一个服务器设备的情况下,确定设备系统异常;
在判定出现异常的目标服务器节点不属于同一个服务器设备的情况下,判断出现异常的目标服务器节点是否属于同一个服务器集群;
在判定出现异常的目标服务器节点属于同一个服务器集群的情况下,判断交易情况是否异常;
在判定交易情况不异常的情况下,确定接入层节点异常。
3.根据权利要求2所述的方法,其特征在于,所述配置信息包括服务器类型、服务器节点所属集群、IP地址、物理设备信息、机房信息中的至少一种。
4.根据权利要求2所述的方法,其特征在于,所述交易包括支付类交易和非支付类交易。
5.根据权利要求2所述的方法,其特征在于,所述根据所述日志信息计算交易处理过程中的指标信息包括:根据所述日志信息分别计算交易处理过程中支付类交易的指标信息和非支付类交易的指标信息。
6.根据权利要求2所述的方法,其特征在于,所述指标信息包括多个指标值;所述指标值包括交易率、成功率、响应时间、异常返回占比中的至少二种。
7.根据权利要求2所述的方法,其特征在于,根据以下方式确定所述指标信息出现异常:
分别判断所述指标信息中的指标值是否处于预设区间;其中,不同的指标值对应有不同的预设区间;
在所述指标信息中至少一个指标值处于预设区间的情况下,确定所述指标信息出现异常。
8.根据权利要求2所述的方法,其特征在于,所述交易情况包括:支付类交易的指标信息波动情况和非支付类交易的指标信息波动情况。
9.根据权利要求2所述的方法,其特征在于,所述方法还包括:
从数据库中查找所述故障原因对应的处理策略,以便于根据所述处理策略对故障进行修复。
10.一种故障原因确定装置,其特征在于,所述装置包括:
接收模块,用于接收多个服务器节点的日志信息;
获取模块,用于获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;
计算模块,用于根据所述日志信息计算交易处理过程中的指标信息;
获得模块,用于在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;
确定模块,用于基于所述交易情况和所述目标服务器节点的配置信息确定故障原因;
其中,确定模块具体用于:
判断出现异常的目标服务器节点是否属于同一个服务器设备;
在判定出现异常的目标服务器节点属于同一个服务器设备的情况下,确定设备系统异常;
在判定出现异常的目标服务器节点不属于同一个服务器设备的情况下,判断出现异常的目标服务器节点是否属于同一个服务器集群;
在判定出现异常的目标服务器节点属于同一个服务器集群的情况下,判断交易情况是否异常;
在判定交易情况不异常的情况下,确定接入层节点异常。
11.一种电子设备,其特征在于,包括:
存储器,用于存储计算机程序;
处理器,用于执行所述计算机程序以实现:接收多个服务器节点的日志信息;获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因;
其中,基于所述交易情况和所述目标服务器节点的配置信息确定故障原因,包括:
判断出现异常的目标服务器节点是否属于同一个服务器设备;
在判定出现异常的目标服务器节点属于同一个服务器设备的情况下,确定设备系统异常;
在判定出现异常的目标服务器节点不属于同一个服务器设备的情况下,判断出现异常的目标服务器节点是否属于同一个服务器集群;
在判定出现异常的目标服务器节点属于同一个服务器集群的情况下,判断交易情况是否异常;
在判定交易情况不异常的情况下,确定接入层节点异常。
12.一种计算机可读存储介质,其特征在于,其上存储有计算机指令,所述指令被执行时实现:接收多个服务器节点的日志信息;获取包括多个配置信息的配置列表;其中,每个配置信息用于表征一个服务器节点;根据所述日志信息计算交易处理过程中的指标信息;在所述指标信息出现异常的情况下,基于所述指标信息与所述配置列表,获得交易情况和出现异常的目标服务器节点;基于所述交易情况和所述目标服务器节点的配置信息确定故障原因;
其中,基于所述交易情况和所述目标服务器节点的配置信息确定故障原因,包括:
判断出现异常的目标服务器节点是否属于同一个服务器设备;
在判定出现异常的目标服务器节点属于同一个服务器设备的情况下,确定设备系统异常;
在判定出现异常的目标服务器节点不属于同一个服务器设备的情况下,判断出现异常的目标服务器节点是否属于同一个服务器集群;
在判定出现异常的目标服务器节点属于同一个服务器集群的情况下,判断交易情况是否异常;
在判定交易情况不异常的情况下,确定接入层节点异常。
CN202011465772.4A 2020-12-14 2020-12-14 一种故障原因确定系统、方法及装置 Active CN112559300B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011465772.4A CN112559300B (zh) 2020-12-14 2020-12-14 一种故障原因确定系统、方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011465772.4A CN112559300B (zh) 2020-12-14 2020-12-14 一种故障原因确定系统、方法及装置

Publications (2)

Publication Number Publication Date
CN112559300A CN112559300A (zh) 2021-03-26
CN112559300B true CN112559300B (zh) 2024-03-01

Family

ID=75064460

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011465772.4A Active CN112559300B (zh) 2020-12-14 2020-12-14 一种故障原因确定系统、方法及装置

Country Status (1)

Country Link
CN (1) CN112559300B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114285727A (zh) * 2022-01-04 2022-04-05 中国建设银行股份有限公司 网络传输异常的处理方法、装置、电子设备及存储介质
CN114966304A (zh) * 2022-04-13 2022-08-30 中移互联网有限公司 故障定位方法、装置及电子设备
CN116980463B (zh) * 2023-09-22 2024-01-30 湖南三湘银行股份有限公司 一种基于探测报文系统交易自动切换的方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011113473A (ja) * 2009-11-30 2011-06-09 Hitachi Omron Terminal Solutions Corp 取引処理システム及びその情報収集方法
CN106789251A (zh) * 2016-12-23 2017-05-31 中国银行股份有限公司 网银运行状态监控系统及方法
CN110928718A (zh) * 2019-11-18 2020-03-27 上海维谛信息科技有限公司 一种基于关联分析的异常处理方法、系统、终端及介质
CN111221702A (zh) * 2019-11-18 2020-06-02 上海维谛信息科技有限公司 基于日志分析的异常处理方法、系统、终端及介质
CN111611100A (zh) * 2020-05-26 2020-09-01 中国工商银行股份有限公司 交易故障检测方法、装置、计算设备以及介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011113473A (ja) * 2009-11-30 2011-06-09 Hitachi Omron Terminal Solutions Corp 取引処理システム及びその情報収集方法
CN106789251A (zh) * 2016-12-23 2017-05-31 中国银行股份有限公司 网银运行状态监控系统及方法
CN110928718A (zh) * 2019-11-18 2020-03-27 上海维谛信息科技有限公司 一种基于关联分析的异常处理方法、系统、终端及介质
CN111221702A (zh) * 2019-11-18 2020-06-02 上海维谛信息科技有限公司 基于日志分析的异常处理方法、系统、终端及介质
CN111611100A (zh) * 2020-05-26 2020-09-01 中国工商银行股份有限公司 交易故障检测方法、装置、计算设备以及介质

Also Published As

Publication number Publication date
CN112559300A (zh) 2021-03-26

Similar Documents

Publication Publication Date Title
CN112559300B (zh) 一种故障原因确定系统、方法及装置
CN109615495B (zh) 一种数据的对账方法、装置、设备及系统
CN103782573B (zh) 对客户端和应用掩盖服务器停运
CN100375038C (zh) 重定序两阶段提交中的资源的最后代理优化方法和系统
CN109840837B (zh) 财务数据的处理方法、装置、计算机可读介质及电子设备
CN110503551B (zh) 一种网络资金交易渠道维护方法、装置和设备
US20130144782A1 (en) Electronic invoice payment prediction system and method
CN113205402A (zh) 对账方法、装置、电子设备及计算机可读介质
CN110942392A (zh) 一种业务数据处理方法、装置、设备和介质
CN108765106A (zh) 一种业财一体化的财务凭证生成方法
CN109614263B (zh) 一种容灾数据处理方法、装置及系统
US11551230B2 (en) Security attack detections for transactions in electronic payment processing networks
CN111833182A (zh) 识别风险对象的方法和装置
US20070067238A1 (en) System and method for transferring information between financial accounts
US10872369B1 (en) Systems and methods for providing intelligent electronic communications
WO2023039143A1 (en) Reconciliating payment transactions performed by a payment service provider
CN114881739A (zh) 订单事件处理方法及装置、电子设备和存储介质
CN112214506B (zh) 一种信息采集方法、装置及存储介质
US20220164868A1 (en) Real-time online transactional processing systems and methods
CN108765107A (zh) 一种业财一体化下的数据保存方法
CN114820158A (zh) 基于规则引擎的银行监管证券数据方法和装置
CN114444120A (zh) 一种基于区块链的融资方法、装置、电子设备和存储介质
CN113971007B (zh) 信息处理方法、装置、电子设备及介质
CN115481990A (zh) 一种智能路由系统、方法、计算机设备及可存储介质
CN116775230A (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
GR01 Patent grant
GR01 Patent grant