CN112887123A - 一种基于调用链的业务报警方法、系统及装置 - Google Patents

Abstract

本发明实施例提供一种基于调用链的业务报警方法、系统及装置，该方法包括：获取当前收集周期内的业务异常数据；对获取的业务异常数据进行分析，得到类调用链；所述类调用链包括异常业务及其调用关系；根据预设的匹配规则，判断是否存在与所述类调用链相匹配的基础调用链；所述基础调用链包括具有调用关系的业务及其调用关系；若存在，根据匹配到的基础调用链定位故障业务，向相匹配的基础调用链中的业务发送业务报警信息；若不存在，根据所述类调用链定位故障业务，向类调用链中的业务发送业务报警信息。能够准确定位故障位置、及时快速的进行故障处理。

Description

一种基于调用链的业务报警方法、系统及装置

技术领域

本发明涉及故障处理技术领域，尤指一种基于调用链的业务报警方法、系统及装置。

背景技术

在业务系统中，服务和服务之间由于调用关系会形成基础调用链，例如：客户端访问业务A，业务A需要调用业务B，而业务B需要调用业务C和业务D的数据经过一系列处理后返回给业务A，业务A再返回给客户端。那么A-B-C就是一条基础调用链，A-B-D也是一条基础调用链。

当出现业务故障时，业务方会发出报警，而业务A、业务B、业务C和数据库可能会分别隶属于不同的部门，客户端请求业务A，业务A调用业务B出错，业务B调用业务C出错，业务C调用数据库报错，最终导致客户端访问异常，这种情况下，业务A、业务B、业务C和数据库分别会接收到自己的业务报警。在后续进行业务报警处理时，业务A发现是调用业务B异常，业务B发现是调用业务C异常，业务C发现是调用数据库异常，经过业务A、B、C及数据库互相联系，确认是数据库异常导致一连串服务异常。

上述业务故障报警及处理实现过程，每个业务只对自己的业务做报警，故障发生时，尤其是调用链末端业务调用失败引发故障时，会导致调用链上所有的服务都报警，故障定位不够准确；且每个业务都会到自己的业务报警并进行排查，从而导致多个业务都需要排查故障点，经过一系列的分析和排查，最终才能确定导致异常的业务位置，大大增加了故障排查的时长；由于调用链上的业务发生报警，各个业务都会去找调用出错方，调用出错的服务很可能是跨部门跨团队的服务，此时涉及到跨部门的沟通，使得故障处理起来非常的繁琐和困难。

发明内容

本发明实施例提供一种基于调用链的业务报警方法、系统及装置，用以解决现有技术中存在的业务预警定位不准确、故障处理繁琐困难、排查时间长等问题。

本发明实施例提供了一种基于调用链的业务报警方法，包括：

获取当前收集周期内的业务异常数据；

对获取的业务异常数据进行分析，得到类调用链；所述类调用链包括异常业务及其调用关系；

根据预设的匹配规则，判断是否存在与所述类调用链相匹配的基础调用链；所述基础调用链包括具有调用关系的业务及其调用关系；

若存在，根据匹配到的基础调用链定位故障业务，向相匹配的基础调用链中的业务发送业务报警信息；

若不存在，根据所述类调用链定位故障业务，向类调用链中的业务发送业务报警信息。

在一些可选的实施例中，所述对获取的业务异常数据进行分析，得到类调用链，包括：

根据获取的业务异常数据中包括的异常业务的标识信息、调用接口和被调用接口，确定异常业务及其调用关系，得到至少一个类调用链。

在一些可选的实施例中，所述根据预设的匹配规则，判断是否存在与所述类调用链相匹配的基础调用链，包括：

遍历存储的基础调用链，判断所述类调用链与遍历到的每一个基础调用链之间的匹配度是否超过设定的匹配度阈值，若是，确定当前的基础调用链与所述类调用链相匹配。

在一些可选的实施例中，所述匹配度阈值包括比例阈值；

判断所述类调用链与遍历到的每一个基础调用链之间的匹配度是否超过设定的匹配度阈值，包括：

针对遍历到的任一基础调用链，确定所述类调用链中与当前的基础调用链中的相同业务数量；

确定所述相同业务数量占当前的基础调用链中总业务数量的比例，判断所述比例是否超过预设的比例阈值。

在一些可选的实施例中，根据匹配到的基础调用链定位故障业务，向相匹配的基础调用链中的业务发送业务报警信息，包括：

根据匹配到的基础调用链中业务之间的调用关系，将位于基础调用链最末端的业务定位为故障业务；

生成包括基础调用链信息、类调用链信息、故障业务和故障业务报错信息的业务报警信息。

在一些可选的实施例中，还包括：

若不存在与所述类调用链相匹配的基础调用链，进一步判断获取业务异常数据的次数是否超过设定的次数阈值；

若否，返回获取下一个收集周期内的业务异常数据，并继续执行对获取的业务异常数据进行分析的步骤；若是，执行根据所述类调用链定位故障业务的步骤。

在一些可选的实施例中，上述方法还包括：

从业务和业务接口的异常日志中收集业务异常数据存储到数据库中；

获取当前收集周期内的业务异常数据，具体包括：

根据预设的业务类型和收集周期，从所述数据库中获取业务异常数据；

所述业务异常数据中包括业务名称、报错时间、业务字段、调用接口、被调用接口、报错信息中的至少一项。

本发明实施例还提供一种基于调用链的业务报警装置，包括：

获取模块，用于获取当前收集周期内的业务异常数据；

分析模块，用于对获取的业务异常数据进行分析，得到类调用链；所述类调用链包括异常业务及其调用关系；

匹配模块，用于根据预设的匹配规则，判断是否存在与所述类调用链相匹配的基础调用链；所述基础调用链包括具有调用关系的业务及其调用关系；

报警模块，用于若所述匹配模块确定存在相匹配的基础调用链，根据匹配到的基础调用链定位故障业务，向相匹配的基础调用链中的业务发送业务报警信息；若所述匹配模块确定不存在相匹配的基础调用链，根据所述类调用链定位故障业务，向类调用链中的业务发送业务报警信息。

本发明实施例还提供一种基于调用链的业务报警系统，包括：分布式业务服务器集群、分布式日志存储服务器集群和分布式日志分析服务器集群；

所述分布式业务服务器集群各服务器收集业务异常数据；

所述分布式日志存储服务器集群，用于存储收集分的业务异常数据；

分布式日志分析服务器集群中设置有上述的基于调用链的业务报警装置，用于从分布式日志收集服务器集群中获取业务异常数据提供给所述基于调用链的业务报警装置进行分析。

本发明实施例还提供一种计算机存储介质，所述计算机存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现上述的基于调用链的业务报警方法。

上述技术方案具有如下有益效果：通过分析收集到的异常业务数据，得到具有调用关系的异常业务组成的类调用链，将类调用链与存储的基础调用链进行匹配，基于匹配结果定位故障业务，相比于对异常业务逐一进行排查的方式，大大减少了需要排查的故障点数量，减少了故障处理的时长，提高了分析速度，而且能够更准确的定位出调用链中发生故障的业务，无需跨部门沟通去调用出错的业务，使故障处理更简单、方便、快捷。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例一中基于调用链的业务报警方法的流程图；

图2是本发明实施例二中基于调用链的业务报警方法的流程图；

图3是本发明实施例三中基于调用链的业务报警方法的流程图；

图4是本发明实施例三中系统物理架构图；

图5是本发明实施例中基于调用链的业务报警系统的结构示意图；

图6是本发明实施例中基于调用链的业务报警装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了解决现有技术中业务报警及处理过程中存在故障定位也不准确、故障处理繁琐困难、多业务分别排查分析导致故障排查时间长等问题，本发明实施例提供一种基于调用链的业务报警方法，基于调用链进行故障报警、定位和处理，处理过程简单，能够快速、准确的定位出故障点。

实施例一

本发明实施例一提供的基于调用链的业务报警方法，其流程如图1所示，包括如下步骤：

步骤S101：获取当前收集周期内的业务异常数据。

业务异常数据可以是预先收集并存储在数据库中的，需要时可以获取，各业务的异常数据是得到类调用链的前提和基础。例如：可以存储在ClickHouse数据库中，ClickHouse数据库是一个开源的数据分析数据库，具有很高的读写性能。

步骤S102：对获取的业务异常数据进行分析，得到类调用链。

对一段时间内的业务异常数据进行分析，得到有调用关系的报错业务组成的类调用链，比如对5秒内或10秒内的异常业务数据进行分析，计算出类调用链。

可选的，根据获取的业务异常数据中包括的异常业务的标识信息、调用接口和被调用接口，确定异常业务及其调用关系，得到至少一个类调用链。其中类调用链包括报错业务及其调用关系。

步骤S103：根据预设的匹配规则，判断是否存在与类调用链相匹配的基础调用链。若存在，执行步骤S104；若不存在，执行步骤S105。

将计算出的类调用链和数据库中存储的基础调用链进行匹配，如果能匹配到符合设定要求的基础调用链，则可以根据匹配出的基础调用链来定位故障业务，否则根据计算出的类调用链定为故障业务。

基础调用链包括具有调用关系的业务及其调用关系。基础调用链是指服务与服务之间的调用关系形成的一条链路。例如：客户端访问业务A，业务A需要调用业务B，而业务B需要调用业务C和业务D的数据经过一系列处理后返回给业务A，业务A再返回给客户端。那么A-B-C就是一条基础调用链，A-B-D也是一条基础调用链。基础调用链业务报警定位和处理的前提和基础，基础调用链的相关信息可以预先存储存在数据库中，例如Mysql数据库中。Mysql数据库是一个开源的关系型数据库。

可选的，可以遍历存储的基础调用链，判断分析得到的类调用链与遍历到的每一个基础调用链之间的匹配度是否超过设定的匹配度阈值，若是，确定当前的基础调用链与类调用链相匹配。可选的，匹配度阈值包括比例阈值，判断类调用链与遍历到的每一个基础调用链之间的匹配度是否超过设定的匹配度阈值时，可以针对遍历到的任一基础调用链，确定类调用链中与当前的基础调用链中的相同业务数量，以及确定相同业务数量占当前基础调用链中总业务数量的比例，判断比例是否超过预设的比例阈值。

步骤S104：根据匹配到的基础调用链定位故障业务，向相匹配的基础调用链中的业务发送业务报警信息。

该步骤中，根据匹配到的基础调用链中业务之间的调用关系，将位于基础调用链最末端的业务定位为故障业务；生成包括基础调用链信息、类调用链信息、故障业务和故障业务报错信息的业务报警信息。

也就是说，如果匹配到符合匹配条件的基础调用链，比如类调用链中包括的业务占基础调用链中包括的业务的数量占比达到一定的阈值，则根据符合匹配条件的基础调用链定为故障业务，比如定位基础调用链最末端的业务为故障业务，然后向基础调用链的所有业务发送业务报警信息。业务报警信息中可以包括定位的故障业务、故障业务的报错信息和基础调用链信息、类调用链信息。

步骤S105：根据类调用链定位故障业务，向类调用链中的业务发送业务报警信息。

如果没有匹配到符合匹配条件的基础调用链，则向类调用链中的所有业务发送业务报警信息。

本实施例的上述方法中，通过分析收集到的异常业务数据，得到具有调用关系的异常业务组成的类调用链，将类调用链与存储的基础调用链进行匹配，基于匹配结果定位故障业务，相比于对异常业务逐一进行排查的方式，大大减少了需要排查的故障点数量，减少了故障处理的时长，提高了分析速度，而且能够更准确的定位出调用链中发生故障的业务，无需跨部门沟通去调用出错的业务，使故障处理更简单、方便、快捷。

实施例二

本发明实施例二提供的基于调用链的业务报警方法的一种可选的实现方式，其流程如图2所示，包括如下步骤：

步骤S201：获取当前收集周期内的业务异常数据。

步骤S202：对获取的业务异常数据进行分析，得到类调用链。

步骤S203：根据预设的匹配规则，判断是否存在与类调用链相匹配的基础调用链。若存在，执行步骤S204；若不存在，执行步骤S205。

步骤S204：根据匹配到的基础调用链定位故障业务，向相匹配的基础调用链中的业务发送业务报警信息。

步骤S205：判断获取业务异常数据的次数是否超过设定的次数阈值。若时，执行步骤S207；若否，执行步骤S206。

本实施例中，当没有匹配到符合匹配条件的基础调用链时，可以增加一个或多个周期的异常数据分析，继续进行基础调用链的匹配，直至匹配周期达到预设数量，比如连续匹配两个或多个周期后，仍未匹配到符合匹配条件的基础调用链，则根据类调用链定为故障业务。

步骤S206：获取下一个收集周期内收集到的业务异常数据，并继续执行步骤S202。

获取到下一个采集周期的异常数据后，可以针对获取到的下一个周期的异常数据进行分析，也可以将获取到的下一个周期的异常数据和之前获取到的异常数据合并到一起进行分析。

步骤S207：根据类调用链定位故障业务，向类调用链中业务发送业务报警信息。

本实施例的上述方法，通过对多个周期的业务异常数据进行分析，基于分析得到的类调用链匹配基础调用链来进行故障业务定位，进一步优化调用链的匹配结果，使故障定位的准确度进一步提高。

可选的，实施例一和实施例二的业务报警方法，在获取当前收集周期内的业务异常数据之前，还可以包括：从业务和业务接口的异常日志中收集业务异常数据存储到数据库中。获取当前收集周期内的业务异常数据时，根据预设的业务类型和收集周期，从数据库中获取业务异常数据。其中，业务异常数据中包括业务名称、报错时间、业务字段、调用接口、被调用接口、报错信息中的至少一项。

实施例三

本发明实施例三提供的基于调用链的业务报警方法一种具体实现方式，其流程如图3所示，系统的物理架构如图4所示，该方法包括如下步骤：

步骤S301：将各个业务和各个业务接口的异常日志统一进行收集并解析，存入到ClickHouse数据库中。

这里收集的异常日志也就是各业务的异常数据，异常日志收集是为了将涉及到基础调用链的各个业务的报错记录收集到一起进行分析，因此会将不同业务的异常数据收集解析并存入到ClickHouse数据库中，收集到的异常数据中主要包括时间、业务字段、调用接口、被调用接口、详细报错信息等。

参见图4所示的系统物理架构，其中包括日志收集和日志分析报警两个部分，其中，日志收集部分从各个业务的业务服务器中收集异常日志，如图4中的业务A、业务B、……、业务N都有各自的分布式服务器集群，每个业务都包括了多个接口，每台服务器上都部署了推送日志的客户端(或说功能模块)。各业务服务器收集到的日志，解析后存储到ClickHouse集群中，ClickHouse集群适用于存储日志数据的分布式服务器集群。

步骤S302：按照配置好的获取频率，从ClickHouse数据库中获取异常日志。

按照配置好的频率获取异常日志，也就相当于按预设的收集周期来进行业务异常数据的获取。例如获取到当前收集周期的异常数据后可以进行后续的分析。

可选的，可以按照配置好的业务类型和频率，定时从ClickHouse数据库中获取异常数据。也就是说可以分业务类型来获取异常数据，针对不同的业务类型分别进行分析。

步骤S303：分析获取的异常日志得到类调用链。

分析报警是将从ClickHouse数据库中按照一定频率提取的业务的异常日志进行分析后，得出类调用链，基于类调用链和基础调用链来判断需要给哪些业务进行报警。

参见图4中日志分析报警部分，包括分析报警服务器集群和mysql数据库，分析报警服务器集群是用于分析类调用链并报警的分布式服务器集群，mysql数据库包括存储基础调用链的mysql数据库以及存储报警数据的mysql数据库。

步骤S304：从存储基础调用链的mysql数据库检索出与类调用链相关的基础调用链。

该步骤中，通过类调用链来去Mysql数据库中匹配基础调用链，通过检索存储基础调用链的mysql数据库，检索出与类调用链相关的基础调用链，例如与类调用链具有至少一个或多个相同业务的基础调用链，较佳的，是检索到与类调用链具有尽可能多的相同业务的基础调用链，即得到与类调用链最接近的基础调用链。

步骤S305：计算出类调用链占基础调用链的业务数占比。

步骤S306：判断占比是否大于设定比例阈值。

若是，执行步骤S307；若否，执行步骤S308；

步骤S307：向基础调用链中的所有业务发送业务报警信息。

此时基于基础调用链定位故障业务，并发送业务报警信息。

步骤S308：判断是否需要继续进行基础调用链的匹配；若是，执行步骤S309；若否，执行步骤S310；

当占比未达到设定的比例阈值时，可以考虑多进行一个或几个采集周期的数据分析。根据配置的分析次数判断确定需要继续进行下一个采集周期的数据分析。比如配置了多分析一个或几个采集周期的异常数据，则判断分析次数是否已经达到次数阈值，如果没达到，则需要继续进行下一个采集周期的异常数据获取。

步骤S309：按预设频率获取下一个采集周期的异常数据，返回执行步骤S303。

获取到下一个采集周期的异常数据后，可选的，可以针对下一个采集周期的异常数据进行分析，还可以获取到的下一个采集周期的异常数据和之前已获取的一个或几个采集周期的异常数据合并到一起，两个采集周期的异常数据一起进行分析。

步骤S310：向类调用链中的所有业务发送业务报警信息。

此时基于类调用链定位故障业务，并发送业务报警信息。

步骤S311：业务报警数据存储到mysql数据库中。

本实施例的上述方法中，占比大于设定的比例阈值，会把业务报警信息发送给基础调用链上涉及到的所有业务，如果是不大于设定的比例阈值，会把业务报警信息发送给类调用链上的所有业务，报警信息中将会详细说明基础调用链和类调用链的信息，最终将报警信息留存到数据库。

详细的日志分析报警过程，通过举例来进行详细说明。

情景一：基础调用链和类调用链可以完全匹配。

例如：业务A有a1接口和a2接口，业务B有b1接口、b2接口和b3接口，业务C有c1接口和c2接口，业务D有d1数据库和d2数据库，2020-09-29 16:00:10～2020-09-2916:00:15这5s内(此时间周期可根据业务需要进行配置，可配置成10s，30s，1分钟等)业务A的a1接口调用业务B的b3接口异常、业务B的b3接口调用业务C的c1接口异常、业务C的c1接口调用业务D的d1数据库异常，通过以上异常数据可分析得出一个类调用链为A(a1)->B(b3)->C(c1)->D(d1)，通过查询Mysql数据库，匹配到了基础调用链A(a1)->B(b3)->C(c1)->D(d1)，从匹配到的基础调用链中可以定位到故障点是业务D的d1数据库，最终将业务报警信息分别发送给业务A、业务B、业务C、业务D，业务报警信息中包括调用链关系(比如基础调用链信息、类调用链信息)、定位到的故障业务和故障业务的详细报错信息等。此场景为能够精确匹配到基础调用链的场景，即类调用链占基础调用链的业务数占比为100％，大于预设的比例阈值(比如75％)，但系统环境错综复杂，此例子并不能囊括所有的情况。下面继续举例说明部分可能的场景。

情景二：基础调用链和类调用链不能完全匹配。这种情况下可以采用模糊匹配，按照匹配度从高到低进行排序，如果达到配置的匹配度阈值，将会纳入告警。

例如：业务A有a1接口和a2接口，业务B有b1接口、b2接口和b3接口，业务C有c1接口和c2接口，业务D有d1数据库和d2数据库，业务E有e1接口和e2接口，2020-09-29 16:00:10～2020-09-29 16:00:15这5s内(此时间周期可根据业务进行配置，可配置成10s，30s，1分钟等)业务A的a1接口调用业务B的b3接口异常、业务C的c1接口调用业务D的d1数据库异常，通过以上异常数据可分析得出一个不完整的类调用链为A(a1)->B(b3)C(c1)->D(d1)，通过查询Mysql数据库，不能精确匹配到基础调用链，只模糊匹配到了基础调用链1:A(a1)->B(b3)->C(c1)->D(d1)和基础调用链2：A(a1)->B(b3)->C(c1)->D(d1)->E(e2)，遇到此种情况，会根据配置的类调用链业务数占基础调用链业务数的比例阈值75％(此比例阈值可根据业务需要进行配置)来进行计算，类调用链业务数为4，基础调用链1的业务数为4，占比为100％；而基础调用链2的业务数为5，占比为80％；业务报警信息会发送给基础调用链1和基础调用链2的所有业务：业务A、业务B、业务C、业务D，业务E，并且写清楚调用链关系、定位到的故障业务和故障业务的详细报错信息，详细报错信息中会将基础调用链按照匹配度从高到低进行排列。此例子中匹配度高的是基础调用链1，匹配度较低的是基础调用链2，从而达到对各业务调用链的警示作用。

情景三：基础调用链和类调用链不能完全匹配，采用模糊匹配后也没有达到配置的匹配度阈值，就会继续增加一个采集周期的业务异常数据来进一步匹配。

例如：业务A有a1接口和a2接口，业务B有b1接口、b2接口和b3接口，业务C有c1接口和c2接口，业务D有d1数据库和d2数据库，2020-09-29 16:00:10～2020-09-2916:00:15这5s内(此时间周期可根据业务需要进行配置，可配置成10s，30s，1分钟等)业务A的a1接口调用业务B的b3接口异常，通过以上异常数据可分析得出一个不完整的类调用链为A(a1)->B(b3)，通过查询Mysql数据库，不能精确匹配到基础调用链，只模糊匹配到了基础调用链1:A(a1)->B(b3)->C(c1)和基础调用链2：A(a1)->B(b3)->C(c1)->D(d1)，根据配置的类调用链业务数占基础调用链业务数的比例阈值75％(此比例阈值可根据业务需要进行配置)来进行计算，类调用链业务数为2，基础调用链1的业务数为3，占比为67％；而基础调用链2的业务数为4，占比为50％，均未达到比例阈值，那将会触发增加一个采集周期的异常数据来进行对比，过了5s后将会取2020-09-29 16:00:10～2020-09-2916:00:20这10s内的数据再次进行匹配，如果还未匹配成功，将不会继续增加下一个采集周期的异常数据，而是将报警信息发送给类调用链上的业务。

基于同一发明构思，本发明实施例还提供一种基于调用链的业务报警系统，其结构如图5所示，该系统包括分布式业务服务器集群1、分布式日志存储服务器集群2和分布式日志分析服务器集群3；

分布式业务服务器集群1各服务器收集业务异常数据；

分布式日志存储服务器集群2，用于存储收集分的业务异常数据；

分布式日志分析服务器集群3中设置基于调用链的业务报警装置，用于从分布式日志收集服务器集群中获取业务异常数据提供给基于调用链的业务报警装置进行分析。

上述基于调用链的业务报警装置的结构如图6所示，包括：

获取模块11，用于获取当前收集周期内的业务异常数据；

分析模块12，用于对获取的业务异常数据进行分析，得到类调用链；类调用链包括异常业务及其调用关系；

匹配模块13，用于根据预设的匹配规则，判断是否存在与所述类调用链相匹配的基础调用链；基础调用链包括具有调用关系的业务及其调用关系；

报警模块14，用于若匹配模块13确定存在相匹配的基础调用链，根据匹配到的基础调用链定位故障业务，向相匹配的基础调用链中的业务发送业务报警信息；若匹配模块13确定不存在相匹配的基础调用链，根据类调用链定位故障业务，向类调用链中的业务发送业务报警信息。

可选的，分析模块12，具体用于根据获取的业务异常数据中包括的异常业务的标识信息、调用接口和被调用接口，确定异常业务及其调用关系，得到至少一个类调用链。

可选的，匹配模块13，具体用于遍历存储的基础调用链，判断类调用链与遍历到的每一个基础调用链之间的匹配度是否超过设定的匹配度阈值，若是，确定当前的基础调用链与类调用链相匹配。

匹配模块13，用于判断类调用链与遍历到的基础调用链的匹配度是否超过设定的匹配度阈值，包括：针对遍历到的任一基础调用链，确定类调用链中与当前的基础调用链中的相同业务数量；确定相同业务数量占当前的基础调用链中总业务数量的比例，判断比例是否超过预设的比例阈值。

可选的，报警模块14，具体用于根据匹配到的基础调用链中业务之间的调用关系，将位于基础调用链最末端的业务定位为故障业务；生成包括基础调用链信息、类调用链信息、故障业务和故障业务报错信息的业务报警信息。

可选的，报警模块14，还用于若匹配模块13判断不存在与所述类调用链相匹配的基础调用链，进一步判断获取业务异常数据次数是否超过设定的次数阈值；若否，通知获取模块11获取下一个收集周期内收集到的业务异常数据，提供给分析模块12继续执行对获取的业务异常数据进行分析的步骤；若是，执行根据类调用链定位故障业务的步骤。

上述装置还包括：收集模块15，用于从业务和业务接口的异常日志中收集业务异常数据存储到数据库中；相应的，获取模块11具体用于根据预设的业务类型和收集周期，从数据库中获取业务异常数据；业务异常数据中包括业务名称、报错时间、业务字段、调用接口、被调用接口、报错信息中的至少一项。

本发明的上述方法、系统和装置，具有如下优点：

1)故障定位相对准确

通过一定的频率来获取某时间段内的各业务的异常数据来定位故障点。例如：最近5s内业务A、业务B和业务C的异常数据，通过对比基础调用链找到业务A、业务B、业务C存在调用链关系，那么锁定业务C异常。

2)故障定位处理及时

通过异常业务的类调用链和基础调用链做匹配，可以很快的定位到故障点并及时处理。

3)故障处理清晰简单

将报警信息分别发送给匹配到基础调用链上的所有业务，各业务方可以清楚的看到匹配到的基础调用链及报警信息，自然而然就可以通过报警信息判断出异常服务位置。

本发明的上述方法、系统和装置，其分析报警特点如下：

可以按照预设检测周期或监测频率进行监控分析，可根据业务类型来定制监测的频率。例如：强依赖型业务(事务型)按照每5s和每10s一次的频率去ClickHouse数据库中拿出所取时间段内的异常业务数据；非强依赖型业务(非事务型)按照每20s和每30s一次的频率去ClickHouse数据库中出拿出所需时间段内的异常业务数据。

可以实现灵活的可视化配置，监测频率可根据业务需要进行修改，如果不进行设置，默认是30s。监测频率和监测总时长(或说周期数)支持定制多个。类调用链业务数占基础调用链业务数的占比的比例阈值值也可灵活配置，例如：类调用链的业务数占基础调用链的业务数占比的比例阈值定义为75％。此部分配置均可在页面中选择进行灵活配置。

可以精准匹配调用链，通过增加一个或几个周期的数据判断和类调用链业务数占基础调用链业务数的占比值使得匹配到的调用链更加的精准。

可以兼容业务类型，支持强依赖的事务型业务和非强依赖的非事务型业务。

具有强大的报警发送功能，精确匹配完调用链后会给涉及到的相关业务方发送报警信息。例如：报警分析中得出的类调用链是1、Mysql数据库中存储的基础调用链是2，如果类调用链1涉及到的业务为业务A、业务B、业务D，而基础调用链2涉及到的业务A、业务B、业务C、业务D，类调用链1所涉及业务数是基础调用链2涉及业务数的75％，将会把报警信息发送给基础调用链2涉及到的所有业务。业务方收到的报警信息包括：当前涉及到报警的调用链是基础调用链2，类调用链1已经全部报警，类调用链报警占比75％等重要信息。此时当业务方看到类调用链1和基础调用链2后，就会很清楚的判断出业务D导致报警的嫌疑最大，那么业务D就可以先进行自查，其他业务协助即可。此报警功能不仅能够准确的定位故障点，同时也节省了各无关业务的时间和人力，更是大大的减少了跨部门跨平台沟通的成本。

可以实现报警数据留存，将报警内容全部存储到数据库中保留作为历史记录，同时也方便后续问题排查使用。

本发明的上述方法、系统和装置，能够灵活制定报警配置和监测频率；支持多类型业务的使用，新增加业务类型，无需对系统二次开发；系统获取信息内容相对固定，开发成本低；程序实现多活，保证高可用；且可以基于现有调用链进行报警

本领域技术人员还可以了解到本发明实施例列出的各种说明性逻辑块(illustrative logical block)，单元，和步骤可以通过电子硬件、电脑软件，或两者的结合进行实现。为清楚展示硬件和软件的可替换性(interchangeability)，上述的各种说明性部件(illustrative components)，单元和步骤已经通用地描述了它们的功能。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本发明实施例保护的范围。

本发明实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路(ASIC)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

本发明实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中，ASIC可以设置于用户终端中。可选地，处理器和存储媒介也可以设置于用户终端中的不同的部件中。

在一个或多个示例性的设计中，本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储与电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(DSL)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、DVD、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于调用链的业务报警方法，其特征在于，包括：

获取当前收集周期内的业务异常数据；

对获取的业务异常数据进行分析，得到类调用链；所述类调用链包括异常业务及其调用关系；

根据预设的匹配规则，判断是否存在与所述类调用链相匹配的基础调用链；所述基础调用链包括具有调用关系的业务及其调用关系；

若存在，根据匹配到的基础调用链定位故障业务，向相匹配的基础调用链中的业务发送业务报警信息；

若不存在，根据所述类调用链定位故障业务，向类调用链中的业务发送业务报警信息。

2.如权利要求1所述的方法，其特征在于，所述对获取的业务异常数据进行分析，得到类调用链，包括：

根据获取的业务异常数据中包括的异常业务的标识信息、调用接口和被调用接口，确定异常业务及其调用关系，得到至少一个类调用链。

3.如权利要求1所述的方法，其特征在于，所述根据预设的匹配规则，判断是否存在与所述类调用链相匹配的基础调用链，包括：

遍历存储的基础调用链，判断所述类调用链与遍历到的每一个基础调用链之间的匹配度是否超过设定的匹配度阈值，若是，确定当前的基础调用链与所述类调用链相匹配。

4.如权利要求3所述的方法，其特征在于，所述匹配度阈值包括比例阈值；

判断所述类调用链与遍历到的每一个基础调用链之间的匹配度是否超过设定的匹配度阈值，包括：

针对遍历到的任一基础调用链，确定所述类调用链中与当前的基础调用链中的相同业务数量；

确定所述相同业务数量占当前的基础调用链中总业务数量的比例，判断所述比例是否超过预设的比例阈值。

5.如权利要求1所述的方法，其特征在于，根据匹配到的基础调用链定位故障业务，向相匹配的基础调用链中的业务发送业务报警信息，包括：

根据匹配到的基础调用链中业务之间的调用关系，将位于基础调用链最末端的业务定位为故障业务；

生成包括基础调用链信息、类调用链信息、故障业务和故障业务报错信息的业务报警信息。

6.如权利要求1所述的方法，其特征在于，还包括：

若不存在与所述类调用链相匹配的基础调用链，进一步判断获取业务异常数据的次数是否超过设定的次数阈值；

若否，获取下一个收集周期内的业务异常数据，并继续执行对获取的业务异常数据进行分析的步骤；若是，执行根据所述类调用链定位故障业务的步骤。

7.如权利要求1-6任一所述的方法，其特征在于，还包括：

从业务和业务接口的异常日志中收集业务异常数据存储到数据库中；

获取当前收集周期内的业务异常数据，具体包括：

根据预设的业务类型和收集周期，从所述数据库中获取业务异常数据；

所述业务异常数据中包括业务名称、报错时间、业务字段、调用接口、被调用接口、报错信息中的至少一项。

8.一种基于调用链的业务报警装置，其特征在于，包括：

获取模块，用于获取当前收集周期内的业务异常数据；

分析模块，用于对获取的业务异常数据进行分析，得到类调用链；所述类调用链包括异常业务及其调用关系；

匹配模块，用于根据预设的匹配规则，判断是否存在与所述类调用链相匹配的基础调用链；所述基础调用链包括具有调用关系的业务及其调用关系；

报警模块，用于若所述匹配模块确定存在相匹配的基础调用链，根据匹配到的基础调用链定位故障业务，向相匹配的基础调用链中的业务发送业务报警信息；若所述匹配模块确定不存在相匹配的基础调用链，根据所述类调用链定位故障业务，向类调用链中的业务发送业务报警信息。

9.一种基于调用链的业务报警系统，其特征在于，包括：分布式业务服务器集群、分布式日志存储服务器集群和分布式日志分析服务器集群；

所述分布式业务服务器集群各服务器收集业务异常数据；

所述分布式日志存储服务器集群，用于存储收集分的业务异常数据；

分布式日志分析服务器集群中设置有如权利要求8所述的基于调用链的业务报警装置，用于从分布式日志收集服务器集群中获取业务异常数据提供给所述基于调用链的业务报警装置进行分析。

10.一种计算机存储介质，其特征在于，所述计算机存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现权利要求1-7任一所述的基于调用链的业务报警方法。

Images