预警方法、装置和系统与流程

本发明涉及运维领域，尤其涉及一种预警方法、装置和系统。
背景技术：
：在传统银行系统中，存在基于多种架构开发的应用产品，这些应用产品使用各式各样的通讯协议连接在一起，构成完整的应用集群，由于这些异构应用产品的存在，对运维工作也提出了较高的要求。目前，中国银行的运维监控方案基本都是根据应用产品来定制，没有统一的机制，当需要排查系统问题或故障时，往往需要多个运维小组协同工作，耗费时间长并且人力成本高。并且随着银行提供的服务渠道越来越丰富，网上银行、手机银行、自助设备、快捷支付服务等，给大家带来便利的同时，也给银行应用系统带来了越来越大的交易压力，对运维的快速发现问题和处理问题提出了挑战。现有技术中都是基于对数据库或日志文件的分析来实现监控预警。但是受制于数据库的限制，存在性能瓶颈，无法实现线性扩展。基于日志文件的分析，需要集中进行二次加工，数据处理需要消耗一定的时间，无法做到实时预警。技术实现要素：本申请的实施例提供一种预警方法、装置和系统，用于实现实时预警。为达到上述目的，本申请的实施例采用如下技术方案：第一方面，提供了一种预警方法，应用于包括至少一个节点的集群应用系统，所述方法包括：从各节点接收应用的交易数据；按照第一周期从多个维度统计所述交易数据的第一统计交易信息，并存储在循环数据库RRD中；按照第二周期对所述第一统计交易信息进行合并得到第二统计交易信息，并根据预警规则和所述第二统计交易信息生成预警信息，其中所述第二周期大于所述第一周期。第二方面，提供了一种预警装置，应用于包括至少一个节点的集群应用系统，所述装置包括：通讯适配器、流式计算引擎和预警引擎；所述通讯适配器用于从各节点接收应用的交易数据；所述流式计算引擎用于按照第一周期从多个维度统计交易数据的第一统计交易信息，并存储在循环数据库RRD中；所述预警引擎用于按照第二周期对第一统计交易信息进行合并得到第二统计交易信息，并根据预警规则和第二统计交易信息生成预警信息，其中所述第二周期大于所述第一周期。第三方面，提供了一种预警系统，包括集群应用系统和如第二方面所述的预警装置，所述集群应用系统包括至少一个节点。第四方面，提供了一种存储一个或多个程序的计算机可读存储介质，所述一个或多个程序包括指令，所述指令当被计算机执行时使所述计算机执行如第一方面所述的方法。本发明的实施例提供的预警方法、装置和系统，，通过按照短周期实时统计交易数据的统计交易信息，并根据一定预警规则和上述统计交易信息来生成预警信息，不需要集中处理所有交易数据的统计信息，缩短处理时间，因此实现了实时预警。附图说明为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。图1为本申请的实施例提供的预警系统的结构示意图；图2为本申请的实施例提供的预警方法的流程示意图一；图3为本申请的实施例提供的应用、节点和统计信息的分布方式示意图；图4为本申请的实施例提供的交易码统计交易信息的数据结构的示意图；图5为本申请的实施例提供的前端系统统计交易信息的数据结构的示意图；图6为本申请的实施例提供的后台系统统计交易信息的数据结构的示意图；图7为本申请的实施例提供的返回码/状态码统计交易信息的数据结构的示意图；图8为本申请的实施例提供的响应时间区间统计交易信息的数据结构的示意图；图9为本申请的实施例提供的自定义数据统计交易信息的数据结构的示意图；图10为本申请的实施例提供的预警方法的流程示意图二。具体实施方式下面结合附图，对本申请的实施例进行描述。参照图1中所示，预警系统包括集群应用系统11、预警装置12和办公邮件平台/短信服务平台13。集群应用系统11包括至少一个节点，应用可以与多个节点交互交易数据，节点可以是服务器。预警装置12从集群应用系统11的各个节点获取交易数据后进行预警分析，最后通过办公邮件平台/短信服务平台13将预警信息通知给监控人员。预警装置12包括通讯适配器121、流式计算引擎122、预警引擎123、预警信息输出引擎124。通讯适配器121负责处理通讯协议接入，例如通过套接字(Socket)、超文本传输协议(HyperTextTransferProtocol，HTTP)、消息队列(MessageQueue，MQ)等接收集群应用系统11发送的数据报文。如果开发人员选择使用某协议(例如Socket、HTTP、MQ等)接入预警装置12，则需要按照预警装置12的规范使用相应的通讯协议接入，并且按照数据接口规范传输数据包。建议通讯适配器121与集群应用系统11之间采用异步通讯机制，当预警装置12出现问题或网络连接故障时，不影响集群应用系统11运行。流式计算引擎122根据计算规则对内存中交易数据进行实时计算，将计算后的结果按一定结构存储在循环数据库(RoundRobinDatabase，RRD)中。预警引擎123可以按多种维度分别统计交易数据并根据预警条件生成预警信息。预警信息输出引擎124可以将预警信息通过办公邮件平台发送给监控人员，也可以将预警信息通过短信服务平台发送给监控人员，当然也可以将预警信息发送到自定义地址或系统，本申请不作限定。需要说明的是，上述各引擎可以为单独设立的处理器，也可以集成在控制器的某一个处理器中实现，此外，也可以以程序代码的形式存储于控制器的存储器中，由控制器的某一个处理器调用并执行以上各单元的功能。这里所述的处理器可以是一个中央处理器(CentralProcessingUnit，CPU)，或者是特定集成电路(ApplicationSpecificIntegratedCircuit，ASIC)，或者是被配置成实施本申请实施例的一个或多个集成电路。具体的，参照图2中所示，本申请提供了一种预警方法，应用于上述系统，该方法包括：S101、通讯适配器从各节点接收应用的交易数据。各种应用包括但不限于网上银行、手机银行、自助设备应用、智能终端APP、快捷支付等应用。通讯适配器不断接收各节点的交易数据，此时各种交易数据仍然存储于内存中。S102、流式计算引擎按照第一周期从多个维度统计交易数据的第一统计交易信息，并存储在循环数据库RRD中。例如第一周期可以为1秒，则流式计算引擎根据计算规则对每一秒中内存中的交易数据进行多个维度的实时计算，将计算后的第一统计交易信息按一定结构存储在RRD中，内存中已有交易数据被清空。相当于RRD中并不存储实际的交易数据，而是存储经过统计计算的第一统计交易信息，其优点在于可以按照时间片实时进行统计，不必集中对海量交易数据进行处理，因此其处理速度更快。需要说明的是该第一周期可以根据实际情况设置，本申请并不限定。多个维度的第一统计信息可以包括以下信息中的至少一个：交易码统计交易信息、前端系统统计交易信息、后台系统统计交易信息、返回码或状态码统计交易信息、响应时间区间统计交易信息、外部交易代码统计交易信息、自定义数据统计交易信息。由于集群应用系统都是由多个节点组成的集群系统，因此上述这些统计信息都是按照应用和节点的结构分别存储的，如图3中所示。交易码统计交易信息的数据结构(核心数据结构)如图4中所示，此存储结构可以记录本应用各个交易/过程的调用情况。响应时间部分分为4个区间，全局响应时间指的是交易/过程的全局处理时间，响应时间分区1记录的是与后台系统的交互时间，响应时间分区2、3记录的是与数据库的交互时间(例如select/update/delete/insert语句等)。当集群应用系统出现性能问题时，响应时间分区1、2、3可以协助判断性能问题产生的原因，按一般运维经验来看，产品类的应用大多数性能问题与数据库有关，而渠道总线类的应用大多数性能问题与后台系统响应缓慢有关。前端系统统计交易信息的数据结构如图5中所示，此结构可以根据前端系统代码记录前端系统调用本应用的交易/过程情况，同时也可以提供本应用的交易/过程响应时间与前端系统的关系。例如，在双11、铁路购票高峰期，网上支付前端系统都是要重点保障的对象，当发现网上支付类前端系统调用本应用响应时间变长时，需要运维人员及时介入处理。后台系统统计交易信息的数据结构如图6中所示，此结构可以根据后台系统代码记录本应用的交易/过程调用后台系统的情况，同时也可以提供本应用的交易/过程响应时间与后台系统的关系。例如，在双11、铁路购票高峰期，有大量交易是通过后台(核心)系统的某个转账交易完成的，此时就需要对这个转账交易进行重点监控，当发现这个转账交易的成功率下降或响应时间变长时，需要运维人员及时介入处理。返回码/状态码统计交易信息的数据结构如图7中所示，此结构可以根据本应用的交易/过程的返回码/状态码进行统计，同时也可以提供本应用的交易/过程响应时间与返回码/状态码之间的关系。例如，进行转账操作时，由于账户余额不足导致失败，对于渠道总线类系统来说，这笔交易认为是成功的(技术成功)，但对于核心系统来说，这笔交易就被认为是失败的(业务失败)。被监控集群应用系统可以根据配置返回码/状态码的规则，实现交易成功率的预警。响应时间区间统计交易信息的数据结构如图8中所示，此结构可以记录交易响应时间区间的分布情况，响应时间区间包括：小于50ms、50-100ms、100-200ms、200-500ms、500-1000ms、1000-2000ms、2000-5000ms、5000-10000ms、大于10000ms。例如，当响应时间大于10000ms的交易大量出现时，意味着当前系统出现了性能问题，需要运维人员重点关注。需要说明的是，该区间仅是示例性的一种区间划分方式，在实际应用中还可以根据具体情况进行划分，本申请并不限定上述范围。外部交易代码统计交易信息指与内部交易码相对应的多种外部交易码分别进行统计，例如对于快捷支持的内部交易码，可能对应手机支付、网银支付等不同外部交易代码，分别统计对应类型的外部交易代码便于分析具体交易来源，后续可以据此进行功能扩展。自定义数据统计交易信息的数据结构如图9中所示，此结构可以由应用自由使用，用来统计一些例如CPU使用率、内存使用率、线程池、数据库连接池等一些系统及公共资源的使用情况，并根据配置做出预警。S103、预警引擎按照第二周期对第一统计交易信息进行合并得到第二统计交易信息，并根据预警规则和第二统计交易信息生成预警信息。其中第二周期大于第一周期，例如第二周期可以为60秒即1分钟，则预警引擎每采集流式计算引擎生成的60个第一统计交易信息后，将这些数据做合并处理，然后可以进一步进行预警处理。可以支持按如下维度分别统计第二统计交易信息：按节点统计、按交易统计、按前端系统统计、按后台系统统计、按返回码/状态码统计、按响应时间区间统计等。预警值可以包括例如：成功率、并发数、响应时间全局、响应时间分区1/2/3等。比较方式可以包括例如按绝对值、百分比、偏差等进行比较。预警规则可以包括预警条件标识、使能标识、预警分类、节点标识、预警规则匹配模式、预警规则匹配方式、预警值类型、阈值、阈值类型、比较方式、预警信息等。具体的，可以通过断言<assert.......>表示一条预警规则，示例性的格式如下所示：<assertid＝"A0001"enabled＝"true"category＝"nodename"nodename＝"*"pattern＝"*"match＝"each"type＝"success"thresholdtype＝"abs"compare＝"less"threshold＝"0.8"param＝"0000"desc＝""/>id：预警条件标识，用于唯一标识所述预警规则，为自定义格式，需保证其唯一性。由于id会写入采样信息数据库永久保存，为避免查询历史记录时产生混淆，id一旦定义，不可复用。enabled：使能标识，用于指示是否启用该预警规则。category：预警分类，用于指示按照所述第一统计信息中的类别计算预警值，其有效值如表1中所示：表1值描述nodename表示按应用或节点计算预警值。trancode表示按交易码计算预警值。frontsystem表示按前端系统计算预警值。serversystem表示按后台系统计算预警值。retcode表示按返回码计算预警值。statuscode表示按状态码/错误码计算预警值。rtrange表示按响应时间区间计算预警值。nodename：节点标识，用于指示预警规则生效的节点，支持正则表达式，填写“*”表示匹配全部节点，如果填写具体节点标识后，计算某些预警值时，只计算指定节点。pattern：预警规则匹配模式，用于指示匹配所述第一统计信息中的类别中的预警项。支持正则表达式，填写“*”表示匹配全部。例如，可以配置交易码、前端/后台系统代码等。match：预警规则匹配方式，用于指示针对单个节点匹配所述预警项还是针对所有节点匹配所述预警项。有效值如表2中所示：表2type：预警值类型，用于指示计算的预警值为成功率、并发数或响应时间。有效值如表3中所示：表3thresholdtype：阈值类型，用于指示阈值为绝对值或百分比。有效值如表4中所示：表4值描述abs绝对值。percent百分比，预警值类型为success时，必须使用百分比。compare：比较方式，用于指示预警值大于或小于阈值时触发预警。有效值如表5中所示：表5值描述more当预警值大于阈值时触发预警。less当预警值小于阈值时触发预警。threshold：预警阈值，用于与预警值进行比较的门限。param：参数项，用于指定成功返回码。多个参数以“,”分隔。desc:预警信息。下面针对每种预警分类category解释预警规则的配置：表6、category＝nodename举例如下：<assertid＝"A001"enabled＝"true"category＝"nodename"nodename＝"*"pattern＝"*"match＝"each"type＝"concurrent"thresholdtype＝"abs"compare＝"more"threshold＝"100"param＝""desc＝"节点并发数超过100"/>例如系统A有2个节点，上述配置含义为当任意一个节点并发数超过100时触发预警。<assertid＝"A002"enabled＝"true"category＝"nodename"nodename＝"*"pattern＝"VIP_\w{1}"match＝"all"type＝"concurrent"thresholdtype＝"abs"compare＝"more"threshold＝"100"param＝""desc＝"VIP节点并发数超过100"/>例如系统A有4个节点，分别为VIP_1、VIP_2、NORMAL_1、NORMAL_2，上述配置含义为当VIP_1与VIP_2节点并发数之和大于100时触发预警。<assertid＝"A003"enabled＝"true"category＝"nodename"nodename＝"*"pattern＝"*"match＝"each"type＝"success"thresholdtype＝"percent"compare＝"less"threshold＝"0.9"param＝"0000,0001"desc＝"节点交易成功率低于90％"/>例如系统A有2个节点，设置成功返回码为0000或0001，上述配置含义为当任意一个节点返回码为0000或0001的交易占比低于0.9(90％)时触发预警。<assertid＝"A004"enabled＝"true"category＝"nodename"nodename＝"*"pattern＝"*"match＝"each"type＝"rttotal"thresholdtype＝"abs"compare＝"more"threshold＝"5000"param＝""desc＝"节点平均响应时间超过5000ms"/>例如系统A有2个节点，上述配置含义为当任意一个节点全局平均响应时间超过5000ms时触发预警。表7、category＝trancode举例如下：<assertid＝"T001"enabled＝"true"category＝"trancode"nodename＝"NODE_1"pattern＝"*"match＝"each"type＝"concurrent"thresholdtype＝"abs"compare＝"more"threshold＝"100"param＝""desc＝"NODE_1节点交易并发数超过100"/>例如系统A的NODE_1上有2个交易，上述配置含义为当任意一个交易并发数超过100时触发预警。<assertid＝"T002"enabled＝"true"category＝"trancode"nodename＝"*"pattern＝"E020\w{2}"match＝"all"type＝"concurrent"thresholdtype＝"abs"compare＝"more"threshold＝"100"param＝""desc＝"E020业务并发数超过100"/>例如系统A有10个交易，上述配置含义为以E020开头的交易并发数之和大于100时触发预警。<assertid＝"T003"enabled＝"true"category＝"nodename"nodename＝"VIP_\w{1}"pattern＝"*"match＝"each"type＝"success"thresholdtype＝"percent"compare＝"less"threshold＝"0.9"param＝"0000,0001"desc＝"VIP_1节点交易成功率低于90％"/>例如系统A的VIP_1、VIP_2节点有10个交易，设置成功返回码为0000或0001，上述配置含义为当VIP_1、VIP_2节点返回码为0000或0001的交易统计值占每只交易总量的比例低于0.9(90％)时触发预警，如交易Tran001总共发生了100笔，有80笔返回码为0000或0001，则交易Tran001成功率为80％，触发预警。<assertid＝"T004"enabled＝"true"category＝"trancode"nodename＝"*"pattern＝"*"match＝"each"type＝"rttotal"thresholdtype＝"abs"compare＝"more"threshold＝"5000"param＝""desc＝"交易平均响应时间超过5000ms"/>例如系统A有10个交易，上述配置含义为当任意一个交易全局平均响应时间超过5000ms时触发预警。表8、category＝frontsystem举例如下：<assertid＝"F001"enabled＝"true"category＝"frontsystem"nodename＝"*"pattern＝"FRONT_A"match＝"all"type＝"rttotal"thresholdtype＝"abs"compare＝"more"threshold＝"5000"param＝""desc＝"BOCNET平均响应时间超过5000ms"/>上述配置含义为FRONT_A调用本应用的全局平均响应时间超过5000ms时触发预警。<assertid＝"F002"enabled＝"true"category＝"frontsystem"nodename＝"*"pattern＝"FRONT_\w{4}"match＝"each"type＝"concurrent"thresholdtype＝"abs"compare＝"more"threshold＝"100"param＝""desc＝"分行中间业务平台并发数超过100"/>上述配置含义为任意一个以FRONT_开头的前端系统并发数大于100时触发预警。表9、category＝serversystem举例如下：<assertid＝"S001"enabled＝"true"category＝"serversystem"nodename＝"*"pattern＝"SVR\w+"match＝"all"type＝"rttotal"thresholdtype＝"abs"compare＝"more"threshold＝"5000"param＝""desc＝"BOCS平均响应时间超过5000ms"/>上述配置含义为SVR开头的后台系统全局平均响应时间超过5000ms时触发预警。<assertid＝"S002"enabled＝"true"category＝"serversystem"nodename＝"*"pattern＝"SVR\w{4}"match＝"each"type＝"concurrent"thresholdtype＝"abs"compare＝"more"threshold＝"100"param＝""desc＝"分行中间业务平台并发数超过100"/>上述配置含义为任意一个以SVR开头的后台系统并发数大于100时触发预警。表10、category＝retcode举例如下：<assertid＝"R001"enabled＝"true"category＝"retcode"nodename＝"*"pattern＝"ERR1"match＝"all"type＝"concurrent"thresholdtype＝"abs"compare＝"more"threshold＝"100"param＝""desc＝"超时交易超限"/>上述配置含义为返回码为ERR1的交易并发数超过100时触发预警。表11、category＝statuscode举例如下：<assertid＝"S001"enabled＝"true"category＝"statuscode"nodename＝"*"pattern＝"APERR"match＝"all"type＝"concurrent"thresholdtype＝"abs"compare＝"more"threshold＝"100"param＝""desc＝"应用失败交易超限"/>上述配置含义为状态码/错误码为APERR的交易并发数超过100时触发预警。表12、category＝rtrange表13、pattern取值值描述LESS_THAN_50小于50ms50_TO_10050ms-100ms之间100_TO_150100ms-150ms之间150_TO_200150ms-200ms之间200_TO_300200ms-300ms之间300_TO_500300ms-500ms之间500_TO_1000500ms-1000ms之间1000_TO_20001000ms-2000ms之间2000_TO_50002000ms-5000ms之间5000_TO_100005000ms-10000ms之间MORE_THAN_10000大于10000ms举例如下：<assertid＝"RT001"enabled＝"true"category＝"rtrange"nodename＝"*"pattern＝"MORE_THAN_10000"match＝"each"type＝"concurrent"thresholdtype＝"abs"compare＝"more"threshold＝"100"param＝""desc＝""/>例如，预警周期配置为60s，上述配置含义为，在60s内，应用任意节点全局响应时间超过10000ms的交易统计值大于100时触发预警。本申请实施例提供的预警方法，通过按照短周期实时统计交易数据的统计交易信息，并根据一定预警规则和上述统计交易信息来生成预警信息，不需要集中处理所有交易数据的统计信息，缩短处理时间，因此实现了实时预警。参照图10中所示，该预警方法还可以包括步骤S104：S104、预警信息输出引擎通过办公邮件平台或短信服务平台将预警信息发送给监控人员。本发明实施例提供一种存储一个或多个程序的计算机可读存储介质，所述一个或多个程序包括指令，所述指令当被计算机执行时使所述计算机执行如图2、10中所述方法。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(DigitalSubscriberLine，DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(SolidStateDisk，SSD))等。以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本
技术领域：
的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。当前第1页1 2 3