CN112965973A - 基于全链路监控的分布式数据库监控方法及装置 - Google Patents

Abstract

本发明属于大数据技术领域，本发明提供了一种基于全链路监控的分布式数据库监控方法及装置，基于全链路监控的分布式数据库监控方法包括：响应于交易请求，生成交易请求对应的链路；采集链路的信息以及分布式数据库的运行指标；根据信息以及运行指标生成链路对应的拓扑关系；根据拓扑关系监控分布式数据库。本发明从SQL分析视角，可以帮助运维人员发现某条SQL整体查询较慢时，能关联到具体是在哪些链路中耗时较长，然后再下钻分析，先由面及线，找到一条典型的链路，再由线及点，从而分析出现慢SQL环节的原因。

Description

基于全链路监控的分布式数据库监控方法及装置

技术领域

本申请涉及大数据技术领域，特别是全链路监控技术领域，具体涉及一种基于全链路监控的分布式数据库监控方法及装置。

背景技术

随着分布式架构的成熟，大量企业级应用采用分布式和云计算技术，企业生产上运行的节点常常是成千上万的，不同类型的节点间调用关系错综复杂，这些节点往往是跨应用、跨团队、跨园区的，一旦某一环节出错，开发和运维人员定位问题非常困难，往往需要通过海量的离散的日志去排查分析，效率较低。分布式追踪技术的出现，让研发和运维人员能够更好的掌控节点间调用情况，更高效、便捷的排查线上问题，为全链路监控提供了可能。

借助全链路监控技术，可以清晰的看到每笔交易的流向，包括访问关系型数据库时，查询语句的执行情况。比如某笔交易访问了几次数据库，分别访问的是哪个数据库，每次访问的数据库查询语句(SQL语句)是什么，每条语句的执行耗时、是否出错等等。这些都是从链路视角，也就是从交易视角来观测SQL的执行情况。然而，企业在实际运维监控中，仅仅从某个点或者某条线去分析往往是不够的。通常问题不是偶发的，比如某条SQL写的效率不高，执行耗时较长(慢SQL)，那么所有调用这条SQL的交易都会耗时较长。

综上所述，如何监控异常SQL，并和链路形成关联，点线面结合以方便分析SQL，成为亟待解决的问题。

发明内容

本发明属于大数据技术领域，针对现有技术中的问题，本发明从链路视角出发，当发现某条链路存在慢SQL或异常SQL时，能由点及面，掌握这条查询语句的整体运行情况，以便明确是点的问题还是面的问题；另一方面，从SQL分析视角，运维人员发现某条SQL整体查询较慢时，能关联到具体是在哪些链路中耗时较长，然后再下钻分析，先由面及线，找到一条典型的链路，再由线及点，从而详细分析出现慢SQL环节的原因。

为解决上述技术问题，本发明提供以下技术方案：

响应于交易请求，生成所述交易请求对应的链路；

采集所述链路的信息以及分布式数据库的运行指标；

根据所述信息以及所述运行指标生成所述链路对应的拓扑关系；

根据所述拓扑关系监控所述分布式数据库。

一实施例中，所述采集所述链路的信息以及分布式数据库的运行指标，包括：

在所述链路进行埋点；

根据所述埋点采集所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标。

一实施例中，所述根据所述信息以及所述运行指标生成所述链路对应的拓扑关系，包括：

根据所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标生成所述拓扑关系。

一实施例中，所述根据所述拓扑关系监控所述分布式数据库包括：

根据所述拓扑关系计算出其所对应的哈希码；

以所述哈希码为维度，以预设时间对所述分布式数据库进行聚合计算，以生成SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和；

根据所述SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和监控所述分布式数据库。

第二方面，本发明提供一种基于全链路监控的分布式数据库监控装置，该装置包括：

链路生成单元，用于响应于交易请求，生成所述交易请求对应的链路；

信息采集单元，用于采集所述链路的信息以及分布式数据库的运行指标；

拓扑关系生成单元，用于根据所述信息以及所述运行指标生成所述链路对应的拓扑关系；

异常监控单元，用于根据所述拓扑关系监控所述分布式数据库。

一实施例中，所述信息采集单元包括：

埋点模块，用于在所述链路进行埋点；

信息采集模块，用于根据所述埋点采集所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标。

一实施例中，所述拓扑关系生成单元具体用于根据所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标生成所述拓扑关系。

一实施例中，所述异常监控单元包括：

哈希码计算模块，用于根据所述拓扑关系计算出其所对应的哈希码；

聚合计算模块，用于以所述哈希码为维度，以预设时间对所述分布式数据库进行聚合计算，以生成SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和；

数据库监控模块，用于根据所述SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和监控所述分布式数据库。

第三方面，本发明提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现基于全链路监控的分布式数据库监控方法的步骤。

第四方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现基于全链路监控的分布式数据库监控方法的步骤。

从上述描述可知，本发明实施例提供一种基于全链路监控的分布式数据库监控方法及装置，首先响应于交易请求，生成交易请求对应的链路；接着，采集链路的信息以及分布式数据库的运行指标；根据信息以及运行指标生成链路对应的拓扑关系；最后根据拓扑关系监控分布式数据库。

为了弥补现有全链路监控方案在异常SQL监控分析方面的不足，本发明所提出的于全链路监控的分布式数据库监控方法及装置，方便企业点线面结合，全面掌握系统SQL执行情况，以更好的分析SQL问题，具体地：

1、现有技术中的慢SQL或错误SQL监控，只提供了从SQL视角的监控分析。本发明将对SQL的监控(点)与链路拓扑(面)形成关联，便于在分布式架构下，全面的审视系统运行情况。运维人员可以从某个问题SQL出发，从宏观视角掌握问题SQL的依赖关系，评估问题SQL的影响范围。

2、本发明对SQL的监控(点)与链路拓扑(面)形成关联，再通过拓扑关联到具体的链路(线)，点线面结合，问题SQL最终可以关联到具体链路，这样就可以回溯到问题现场，进行充分分析。

附图说明

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

图1为本发明实施例中基于全链路监控的分布式数据库监控方法的流程示意图；

图2为本发明实施例中步骤200的流程示意图；

图3为本发明实施例中步骤300的流程示意图；

图4为本发明实施例中步骤400的流程示意图；

图5为本发明具体应用实例中的基于全链路监控的分布式数据库监控定系统的方块图；

图6为本发明具体应用实例中的链路采集装置的结构示意图；

图7为本发明具体应用实例中的消息中转装置的结构示意图；

图8为本发明具体应用实例中的拓扑分析装置的结构示意图；

图9为本发明具体应用实例中的聚合计算装置的结构示意图；

图10为本发明具体应用实例中的明细存储装置的结构示意图；

图11为本发明具体应用实例中的可视化监控装置的结构示意图；

图12为本发明具体应用实例中的基于全链路监控的分布式数据库监控方法的流程示意图；

图13为本发明的实施例中基于全链路监控的分布式数据库监控装置的结构示意图；

图14为本发明的实施例中信息采集单元的结构示意图；

图15为本发明的实施例中异常监控单元的结构示意图；

图16为本发明的实施例中的电子设备的结构示意图。

具体实施方式

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

本发明的实施例提供一种基于全链路监控的分布式数据库监控方法的具体实施方式，参见图1，其具体包括如下内容：

步骤100：响应于交易请求，生成所述交易请求对应的链路。

可以理解的是，步骤100中的链路是指数据链路。具体地，从交易请求开始生成链路上下文，该链路上下文需要随整条链路透传，以将链路串联起来，并根据链路上下文生成完整的链路。

步骤200：采集所述链路的信息以及分布式数据库的运行指标。

步骤200中的信息包括：TRACEID(标记一条调用链的ID)、SPANID(标记一条链路中本次调用的ID)、PARENTSPANID(上一阶段调用的ID，请求入口这个字段是空)；运行指标又分为指标和明细，指标又包括：是否成功、执行耗时，明细包括SQL语句、TRACEID、SQL语句的hashcode、数据库地址、是否出错、是否是慢SQL、SQL报错堆栈。

步骤300：根据所述信息以及所述运行指标生成所述链路对应的拓扑关系；

在计算机科学中，拓扑关系指分布式网络上的计算机和各种设备实现互联时的抽象连接方式。其不关心每台计算机或设备的细节，关心它们相互的连接关系，并试图将这些关系通过图表示出来。

步骤300在实施时，具体地，根据SPANID、PARENTSPANID将链路串联起来，首先判断链路是否完整，如果不完整(比如串不起来数据缺失)则不予计算直接丢弃。将完整链路处理成拓扑关系，如接口A调用接口B，接口B再调用接口C。再将接口名拼接，算出hashcode(哈希码)。

步骤400：根据所述拓扑关系监控所述分布式数据库。

可以理解的是，分布式追踪技术的监控对象，是每一笔请求(或者叫交易)，通过跟踪请求流向，实现跨进程、跨节点、跨网络的运行监控(监控如网络耗时、节点执行耗时、请求流向等)，所以也叫全链路监控。根据最新的全链路监控标准(OPENTRACING)，分布式追踪技术的原理是通过在请求的入口节点，生成一个ID(即TRACEID)来标记一笔请求，TRACEID会随着整条调用链路透传，从而将分布式节点串联起来。一笔请求经过的每一阶段，通过生成一个SPANID来标记，表示链路的某个步骤。此外，既然要将链路串联起来，还需要知道上一阶段的SPANID，即PARENTSPANID，因此，PARENTSPANID也随网络协议栈透传，这样整条链路得以串联起来，就可以对整条链路的调用情况进行监控。

从上述描述可知，本发明实施例提供一种基于全链路监控的分布式数据库监控方法及装置，首先响应于交易请求，生成交易请求对应的链路；接着，采集链路的信息以及分布式数据库的运行指标；根据信息以及运行指标生成链路对应的拓扑关系；最后根据拓扑关系监控分布式数据库。本发明通过对数据库访问进行拦截，采集SQL执行信息，上报到实时分析数据库进行聚合计算。通过对每一笔链路的拓扑结构计算一个hashcode，将链路和拓扑结构进行关联；对SQL语句计算hashcode，并与链路关联。最终，让SQL和拓扑结构得以关联，从而由点及面，全面审视系统的SQL执行情况。

一实施例中，参见图2，步骤200进一步包括：

步骤201：在所述链路进行埋点；

埋点技术网站分析的一种常用的数据采集方法。是数据采集领域(尤其是用户行为数据采集领域)的术语，是指针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。比如用户某个icon点击次数、观看某个视频的时长等等。埋点的技术实质，是先监听软件应用运行过程中的事件，当需要关注的事件发生时进行判断和捕获。特别注意需要明确事件发生时间点、判别条件，这里如果遇到不清楚的，需要和开发沟通清楚，避免采集数据与理想存在差异。例如：期望采集某个app的某个广告的有效曝光数，有效曝光的判别条件是停留时长超过1秒且有效加载出广告内容。

数据埋点分为初级、中级、高级三种方式。数据埋点是一种良好的私有化部署数据采集方式。

初级：在产品、服务转化关键点植入统计代码，据其独立ID确保数据采集不重复(如购买按钮点击率)；

中级：植入多段代码，追踪用户在平台每个界面上的系列行为，事件之间相互独立(如打开商品详情页——选择商品型号——加入购物车——下订单——购买完成)；

高级：联合公司工程、ETL采集分析用户全量行为，建立用户画像，还原用户行为模型，作为产品分析、优化的基础。

步骤202：根据所述埋点采集所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标。

具体地，通过埋点的方式拦截对数据库的访问，采集SQL执行信息，包括指标和明细，包括：是否成功、执行耗时；SQL语句、TRACEID、SQL语句的hashcode、数据库地址、是否出错、是

否是慢SQL、SQL报错堆栈。根据配置的慢SQL时间与实际执行耗时比对确定(慢SQL时间默认1秒)。

一实施例中，参见图3，步骤300进一步包括：

步骤301：根据所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标生成所述拓扑关系。

具体地，一笔交易经过的每一阶段，可以用一个SPANID(链路节点，该链路节点可以用链路ID，该链路ID可以为链路的标记ID、当前阶段的调用ID、上一阶段的调用ID的标记)来标记，表示该链路的某个步骤。此外，如果要将链路串联起来，还需要知道上一阶段的SPANID，即PARENT SPANID，因此，PARENT SPANID也随网络协议栈透传，以整条链路得以串联起来，形成拓扑关系，需要说明的是，这里的运行指标是指整个SQL运行指标，即SQL的平均执行耗时、次数、成功率、失败数，即在形成拓扑关系过程中，需要对每一个SPANID的运行指标进行限定，以此便于运维人员评估是否有问题，。

一实施例中，参见图4，步骤400进一步包括：

步骤401：根据所述拓扑关系计算出其所对应的哈希码；

可以理解的是，hashcode(哈希码)是用来提高对HashMap哈希表存取对象的使用效率。哈希算法将任意长度的二进制值映射为固定长度的较小二进制值，这个小的二进制的值称为哈希码(哈希值)，哈希值是一段数据唯一且极其紧凑的数值标识形式。

骤402：以所述哈希码为维度，以预设时间对所述分布式数据库进行聚合计算，以生成SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和；

具体地，可利用SQL中的聚合函数(聚合函数对一组值执行计算并返回单一的值。)对分布式数据库进行计算，需要说明的是，所有聚合函数都具有确定性。任何时候用一组给定的输入值调用它们时，都返回相同的值。聚合函数可以应用于查询语句的SELECT中，或者HAVING子句中，但不可用于WHERE语句中，因为WHERE是对逐条的行记录进行筛选。

骤403：根据所述SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和监控所述分布式数据库。

步骤403在实施时，可以将查询出的数据(SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和)进行可视化展示(各种图表)，供开发及运维人员分析。异常SQL分析页面，展示异常SQL及其运行指标，即超过1s的SQL(慢SQL，1s为默认值)以及出错的SQL。在关联分析页面，将具体的SQL与拓扑的关联关系做展示，展示与某条SQL语句相关联的所有拓扑结构。再根据拓扑，关联到具体的链路清单(即拓扑结构相同的链路)，方便运维人员从链路视角，进行精准分析。在链路分析页面，如果链路存在数据库访问，则提供SQL语句的整体运行指标(这条SQL的平均执行耗时、次数、成功率、失败数)，便于运维人员评估是否有问题，比如执行耗时与平均值差距较大。

为进一步地说明本方案，本发明还提供基于全链路监控的分布式数据库监控定方法的具体应用实例，具体包括如下内容。

参见图5，本发明还提供一种基于全链路监控的分布式数据库监控定系统，该系统包括：链路采集装置1、消息中转装置2、拓扑分析装置3、聚合计算装置4、明细存储装置5、可视化监控装置6。装置1与装置2相连；装置2与装置3相连；装置2与装置4相连；装置2与装置5相连；装置3与装置5相连，装置3与装置6相连，装置5与装置6相连。具体地：

链路采集装置1：以埋点的方式采集链路信息，以及SQL运行指标，并上报到装置2.

消息中转装置2：消息的中转站，供装置3、4、5订阅。

拓扑分析装置3：订阅链路信息，并对其进行加工，加工后的数据存储到装置5。

聚合计算装置4：订阅装置2中的指标数据，对其进行聚合计算和存储。

明细存储装置5：从装置2订阅链路数据并存储，接收装置3上报的关系并存储，包括：SQL和链路的关系、SQL语句的hashcode和SQL语句的对应关系、链路和拓扑的关系。

可视化监控装置6：从装置4和装置5中查询各类监控数据，并进行可视化加工和展示。

图6是本发明中链路采集装置1内部结构示意图，如图6所示，链路采集装置1包括：链路采集单元11、SQL信息采集单元12、链路上报单元13、SQL信息上报单元14，其中：

链路采集单元11：从请求入口开始生成链路上下文，链路上下文需要随整条链路透传，以将链路串联起来，主要的字段有：TRACEID(标记一条调用链的ID)、SPANID(标记一条链路中本次调用的ID)、PARENTSPANID(上一阶段调用的ID，请求入口这个字段是空)。单元11同时要采集一些辅助问题分析的信息，比如每个阶段的接口信息、耗时、网络信息等。

SQL信息采集单元12：通过埋点的方式拦截对数据库的访问，采集SQL执行信息，包括指标和明细，指标又包括：是否成功、执行耗时，明细包括SQL语句、TRACEID、SQL语句的hashcode、数据库地址、是否出错、是否是慢SQL、SQL报错堆栈。是否是慢SQL根据配置的慢SQL时间与实际执行耗时比对确定，慢SQL时间默认1秒。

链路上报单元13：将每个阶段采集的链路信息，上报到装置2。

SQL信息上报单元14：将单元12采集的指标(是否成功、执行耗时)、SQL和链路的关系(TRACEID、SQL语句的hashcode、数据库地址、是否出错、是否是慢SQL、SQL报错堆栈)、每条SQL语句的hashcode和SQL语句的对应关系(SQL语句的hashcode、SQL语句)上报到装置2。

图7是本发明中消息中转装置2的内部结构示意图，如图7所示，消息中转装置2包括消息接收单元21、消息订阅单元22，其中：

消息接收单元21：采用kafka消息中间件，接收装置1上报上来的数据，包括4个TOPIC：链路、SQL运行指标、SQL与链路关系、SQL语句的hashcode和SQL语句对应关系。

消息订阅单元22：kafka负责将数据存储到到文件系统，并提供网络接口，数据消费者可以通过接口订阅指定TOPIC的数据。

图8是本发明中拓扑分析装置3的内部结构示意图，如图8所示，拓扑分析装置3包括数据订阅单元31、数据缓存单元32、拓扑计算单元33、数据上报单元34，其中：

数据订阅单元31：订阅装置2中的链路TOPIC，即单元13上报的链路数据。

数据缓存单元32：在内存中以，以TRACEID为key，每阶段的链路数据为value，以键值对的形式，缓存一段时间(默认五分钟)的链路数据。超时后，从缓存中取出，并调用拓扑计算单元33进行计算。

拓扑计算单元33：根据SPANID、PARENTSPANID将链路串联起来，首先判断链路是否完整，如果不完整(比如串不起来数据缺失)则不予计算直接丢弃。将完整链路处理成拓扑关系，如接口A调用接口B，接口B再调用接口C。再将接口名拼接，算出hashcode(哈希码)。

数据上报单元34：将拓扑hashcode和TRACEID的关系，上报至明细存储装置5，即链路和拓扑的关系明细。

图9是本发明中聚合计算装置4的内部结构示意图，聚合计算装置4包括数据拉取单元41、聚合计算单元42、数据存储单元43、数据查询单元44，其中：

数据拉取单元41：采用实时计算数据库Druid，从装置2中消费SQL运行指标这个TOPIC的数据。

聚合计算单元42：Druid针对不同类型指标，以SQL语句的hashcode为维度，按分钟进行聚合计算，主要包括：对SQL执行耗时求平均、对SQL执行次数求和、对SQL成功次数求和、对SQL异常次数求和。

数据存储单元43：将聚合计算后的数据存储至文件系统。

数据查询单元44：提供接口给外部访问，查询存储的数据。

图10是本发明中明细存储装置5的内部结构示意图，如图10所示，明细存储装置5包括数据订阅单元51、数据接收单元52、数据存储单元53、数据查询单元54：

数据订阅单元51：装置5采用Elastic Search数据库，主动从装置2订阅这几个TOPIC的数据：链路、SQL和链路的关系、SQL语句的hashcode和SQL语句的对应关系。并调用数据存储单元53存储到文件系统中指定的表中。

数据接收单元52：Elastic Search数据库接收数据上报单元34上报的拓扑hashcode和TRACEID的关系，即链路和拓扑的关系明细。并调用数据存储单元53存储到文件系统。

数据存储单元53：Elastic Search数据库建立5张表存储明细数据：链路明细表、SQL和链路的关系表、SQL语句的hashcode和SQL语句的对应关系表、链路和拓扑的关系表。

数据查询单元54：提供网络接口，可以查询指定表中的明细数据。

图11是本发明中可视化监控装置6的内部结构示意图，如图11所示，可视化监控装置6包括数据查询单元61、可视化展示单元62：

数据查询单元61：从装置4和装置5中查询数据。从装置4中查询某条SQL的运行指标。从装置5中查询明细数据，如异常SQL清单(慢的和出错的)、某条SQL对应的拓扑清单、某个拓扑结构对应的链路清单、SQL语句的hashcode对应的实际的SQL语句。

可视化展示单元62：将查询出的数据进行可视化展示，供开发及运维人员分析。展示异常SQL及其运行指标，例如：超过1s的SQL(慢SQL，1s为默认值)以及出错的SQL。在关联分析页面，将具体的SQL与拓扑的关联关系做展示，展示与某条SQL语句相关联的所有拓扑结构。再根据拓扑，关联到具体的链路清单(即拓扑结构相同的链路)，方便运维人员从链路视角，进行精准分析。在链路分析页面，如果链路存在数据库访问，则提供SQL语句的整体运行指标(这条SQL的平均执行耗时、次数、成功率、失败数)，便于运维人员评估是否有问题，比如执行耗时与平均值差距较大。

基于上述基于全链路监控的分布式数据库监控定系统，本具体应用实例所提供的基于全链路监控的分布式数据库监控定方法具体包括以下步骤，参见图12。

步骤S101：链路采集装置1通过埋点的方式，采集必要的信息，报错链路数据和SQL的运行数据，采集后的数据处理后，发送到消息中转装置2，主要分为明细和指标。

步骤S102：聚合计算装置4从消息中转装置2中消费SQL运行指标数据，并对指标进行聚合计算。

步骤S103：拓扑分析装置3从装置2中消费链路数据，计算链路的拓扑结构，并将链路和拓扑关系存储到明细存储装置5。

步骤S104：明细存储装置5接收拓扑分析装置3上报上来的明细数据，主动订阅消息中转装置2中的明细数据，将这些数据存储到不同的表中。

步骤S105：可视化监控装置6从聚合计算装置4和装明细存储装置5中查询数据，并进行加工展示，方便运维人员监控和分析。

从上述描述可知，本发明实施例提供一种基于全链路监控的分布式数据库监控方法，针对现有技术中的问题，企业需要点线面结合，有一个能将链路监控和异常SQL监控进行关联分析的解决方案，更好的监控分析系统的数据库查询的执行情况。比如，从链路视角，当发现某条链路存在慢SQL或异常SQL时，能由点及面，掌握这条查询语句的整体运行情况，以便明确是点的问题还是面的问题；从SQL分析视角，运维人员发现某条SQL整体查询较慢时，能关联到具体是在哪些链路中耗时较长，然后再下钻分析，先由面及线，找到一条典型的链路，再由线及点，进行详细分析出现慢SQL环节的原因。

基于同一发明构思，本申请实施例还提供了一种基于全链路监控的分布式数据库监控装置，可以用于实现上述实施例所描述的方法，如下面的实施例。由于基于全链路监控的分布式数据库监控装置解决问题的原理与基于全链路监控的分布式数据库监控方法相似，因此基于全链路监控的分布式数据库监控装置的实施可以参见基于全链路监控的分布式数据库监控方法实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的系统较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本发明的实施例提供一种能够实现基于全链路监控的分布式数据库监控方法的基于全链路监控的分布式数据库监控装置的具体实施方式，参见图13，基于全链路监控的分布式数据库监控装置具体包括如下内容：

链路生成单元10，用于响应于交易请求，生成所述交易请求对应的链路；

信息采集单元20，用于采集所述链路的信息以及分布式数据库的运行指标；

拓扑关系生成单元30，用于根据所述信息以及所述运行指标生成所述链路对应的拓扑关系；

异常监控单元40，用于根据所述拓扑关系监控所述分布式数据库。

一实施例中，参见图14，所述信息采集单元20包括：

埋点模块201，用于在所述链路进行埋点；

信息采集模块202，用于根据所述埋点采集所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标。

一实施例中，所述拓扑关系生成单元30具体用于根据所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标生成所述拓扑关系。

一实施例中，参见图15，所述异常监控单元40包括：

哈希码计算模块401，用于根据所述拓扑关系计算出其所对应的哈希码；

聚合计算模块402，用于以所述哈希码为维度，以预设时间对所述分布式数据库进行聚合计算，以生成SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和；

数据库监控模块403，用于根据所述SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和监控所述分布式数据库。

从上述描述可知，本发明实施例提供一种基于全链路监控的分布式数据库监控装置，基于客户自然属性计算出相似客户的投资方式，得到组合基金推荐产品，并基于客户的收入支出情况使用中位数算法计算产品投资金额比重，从而计算出组合产品的推荐购买金额。本发明不仅解决客户经理或客户遴选产品的困惑，更明确了投资周期和投资金额，提供给客户一种稳定的投资方式，理财组合产品的投资方式也降低了市场波动影响，平衡了产品收益和投资风险。另外，由于是定期自动推送推荐产品购买给客户，也增加了银行对客户的粘性度。

本申请的实施例还提供能够实现上述实施例中的基于全链路监控的分布式数据库监控方法中全部步骤的一种电子设备的具体实施方式，参见图16，电子设备具体包括如下内容：

处理器(processor)1201、存储器(memory)1202、通信接口(CommunicationsInterface)1203和总线1204；

其中，处理器1201、存储器1202、通信接口1203通过总线1204完成相互间的通信；通信接口1203用于实现服务器端设备以及客户端设备等相关设备之间的信息传输；

处理器1201用于调用存储器1202中的计算机程序，处理器执行计算机程序时实现上述实施例中的基于全链路监控的分布式数据库监控方法中的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：响应于交易请求，生成所述交易请求对应的链路；

步骤200：采集所述链路的信息以及分布式数据库的运行指标；

步骤300：根据所述信息以及所述运行指标生成所述链路对应的拓扑关系；

步骤400：根据所述拓扑关系监控所述分布式数据库。

本申请的实施例还提供能够实现上述实施例中的基于全链路监控的分布式数据库监控方法中全部步骤的一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的基于全链路监控的分布式数据库监控方法的全部步骤，例如，处理器执行计算机程序时实现下述步骤：

步骤100：响应于交易请求，生成所述交易请求对应的链路；

步骤200：采集所述链路的信息以及分布式数据库的运行指标；

步骤300：根据所述信息以及所述运行指标生成所述链路对应的拓扑关系；

步骤400：根据所述拓扑关系监控所述分布式数据库。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

虽然本申请提供了如实施例或流程图的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

以上所述仅为本说明书实施例的实施例而已，并不用于限制本说明书实施例。对于本领域技术人员来说，本说明书实施例可以有各种更改和变化。凡在本说明书实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书实施例的权利要求范围之内。

Claims (10)

1.一种基于全链路监控的分布式数据库监控方法，其特征在于，包括：

响应于交易请求，生成所述交易请求对应的链路；

采集所述链路的信息以及分布式数据库的运行指标；

根据所述信息以及所述运行指标生成所述链路对应的拓扑关系；

根据所述拓扑关系监控所述分布式数据库。

2.如权利要求1所述的基于全链路监控的分布式数据库监控方法，其特征在于，所述采集所述链路的信息以及分布式数据库的运行指标，包括：

在所述链路进行埋点；

根据所述埋点采集所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标。

3.如权利要求2所述的基于全链路监控的分布式数据库监控方法，其特征在于，所述根据所述信息以及所述运行指标生成所述链路对应的拓扑关系，包括：

根据所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标生成所述拓扑关系。

4.如权利要求1所述的基于全链路监控的分布式数据库监控方法，其特征在于，所述根据所述拓扑关系监控所述分布式数据库包括：

根据所述拓扑关系计算出其所对应的哈希码；

以所述哈希码为维度，以预设时间对所述分布式数据库进行聚合计算，以生成SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和；

根据所述SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和监控所述分布式数据库。

5.一种基于全链路监控的分布式数据库监控装置，其特征在于，包括：

链路生成单元，用于响应于交易请求，生成所述交易请求对应的链路；

信息采集单元，用于采集所述链路的信息以及分布式数据库的运行指标；

拓扑关系生成单元，用于根据所述信息以及所述运行指标生成所述链路对应的拓扑关系；

异常监控单元，用于根据所述拓扑关系监控所述分布式数据库。

6.如权利要求5所述的基于全链路监控的分布式数据库监控装置，其特征在于，所述信息采集单元包括：

埋点模块，用于在所述链路进行埋点；

信息采集模块，用于根据所述埋点采集所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标。

7.如权利要求6所述的基于全链路监控的分布式数据库监控装置，其特征在于，所述拓扑关系生成单元具体用于根据所述链路的标记ID、当前阶段的调用ID、上一阶段的调用ID以及所述运行指标生成所述拓扑关系。

8.如权利要求5所述的基于全链路监控的分布式数据库监控装置，其特征在于，所述异常监控单元包括：

哈希码计算模块，用于根据所述拓扑关系计算出其所对应的哈希码；

聚合计算模块，用于以所述哈希码为维度，以预设时间对所述分布式数据库进行聚合计算，以生成SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和；

数据库监控模块，用于根据所述SQL执行耗时求平均、SQL执行次数求和、SQL成功次数求和以及SQL异常次数求和监控所述分布式数据库。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至4任一项所述基于全链路监控的分布式数据库监控方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至4任一项所述基于全链路监控的分布式数据库监控方法的步骤。

Images