一种基于图数据的业务监控方法、装置、设备及存储介质与流程

1.本文属于金融科技领域，具体涉及一种基于图数据的业务监控方法、装置、设备及存储介质。


背景技术：

2.近年来，互联网技术的快速发展，特别是金融领域，随着应用架构逐步向服务化转型，业务系统之间的调用层次越来越深，部署情况越来越复杂，实现业务运行可实时监控往往成为一个困难的问题。且当业务系统出现故障时，如何从错综复杂的调用关系中快速分析问题，准确定位引起故障的根因，是当前运维工作中重点关注的问题。目前针对业务系统的监控以及故障定位主要如下手段：对核心业务中运行采用的重点应用进行监控，考虑的是应用独立运行时的故障问题。由于业务运行是以交易链路上的应用的执行为基础的，当该业务运行出现故障时，链路上某环节报警，从而导致上游应用层层报警，在对故障定位时，是对业务交易链路上的应用逐个排除，难以精确快速定位问题根源，因此如何提高业务系统的监控效率，成为目前亟需解决的技术问题。


技术实现要素：

3.针对现有技术的上述问题，本文的目的在于，提供一种基于图数据的业务监控方法、装置、设备及存储介质，能够提高业务系统监控的效率。
4.为了解决上述技术问题，本文的具体技术方案如下：
5.一方面，本文提供一种基于图数据的业务监控方法，所述方法包括：
6.获取针对目标业务的历史日志数据；
7.根据所述历史日志数据，提取获得所述目标业务交易链路中不同维度节点的关联关系；
8.根据所述关联关系生成不同维度节点的关联关系图数据；
9.根据所述图数据，构建生成所述目标业务交易链路中不同维度节点的可视化监控模型；
10.根据所述可视化监控模型，结合预设告警策略，对所述目标业务的运行数据进行监控告警。
11.进一步地，所述不同维度节点包括目标业务交易链路中应用、微服务集群、微服务、容器和数据库的一部分或全部。
12.进一步地，所述根据所述历史日志数据，提取获得所述目标业务交易链路中不同维度节点的关联关系，包括：
13.根据所述历史日志数据中的目标业务运行日志，确定所述目标业务中的全部应用及不同应用之间的互访关系；
14.根据所述目标业务运行日志和所述全部应用，确定每个应用中微服务集群及不同微服务集群之间的互访关系；
15.根据所述微服务集群，获取历史日志数据中的每个所述微服务集群对应的微服务调用日志；
16.根据所述微服务调用日志，确定每个微服务集群中不同微服务之间的互访关系；
17.根据不同应用之间的互访关系、不同微服务集群之间的互访关系和所述不同微服务之间的互访关系，形成所述目标业务交易链路中不同维度节点的第一关联关系。
18.进一步地，根据所述历史日志数据中的目标业务运行日志，确定所述目标业务中的全部应用及不同应用之间的互访关系，包括：
19.从所述目标业务运行日志中提取获得业务运行的源地址和目的地址；
20.根据所述源地址和所述目的地址，确定所述目标业务中的全部应用及不同应用之间的互访关系。
21.进一步地，所述根据所述历史日志数据，提取获得所述目标业务交易链路中不同维度节点的关联关系，还包括：
22.根据所述微服务，获取历史日志数据中的与所述微服务对应的数据接口调用日志；
23.根据所述数据接口调用日志，确定所述微服务和所述容器的对应关系，以及不同容器之间的互访关系；
24.获取历史日志数据中的所述容器对应的数据抓取日志；
25.根据所述数据抓取日志，确定所述容器和所述数据库的对应关系；
26.根据所述微服务和所述容器的对应关系、不同容器之间的互访关系和所述容器和所述数据库的对应关系，确定所述目标业务交易链路中不同维度节点的第二关联关系。
27.进一步地，所述根据所述关联关系生成不同维度节点的关联关系图数据，包括：
28.根据所述关联关系，生成不同维度节点的关联关系文本数据；
29.根据所述文本数据，转换生成不同维度节点的关联关系图数据。
30.进一步地，所述根据所述关联关系生成不同维度节点的关联关系图数据之后还包括：
31.将转换生成的图数据存储至图数据库中。
32.进一步地，所述根据所述图数据，构建生成所述目标业务交易链路中不同维度节点的可视化监控模型，包括：
33.构建基于多维度节点的可视化初始监控模型，所述可视化初始监控模型包括节点类型和节点关联属性；
34.根据所述节点类型，确定每个维度节点对应的图数据，并将所述图数据加载至所述可视化初始监控模型；
35.根据所述节点关联属性，对加载图数据后的可视化初始监控模型进行配置，以得到构建完成的所述目标业务交易链路中不同维度节点的可视化监控模型。
36.作为可选地，所述节点关联属性包括节点类型标识、图数据形状以及互访标识。
37.进一步地，所述根据所述可视化监控模型，结合预设告警策略，对所述目标业务的运行数据进行监控告警，包括：
38.实时获取所述目标业务的运行数据，所述运行数据至少包括以下内容之一：不同维度节点运行时长、不同维度节点运行cpu使用率、数据库调用耗时；
39.根据所述运行数据和预设告警策略，确定不同维度节点的告警信息；
40.根据所述告警信息，在所述可视化监控模型中显示相应的告警提示。
41.进一步地，所述根据所述运行数据和预设告警策略，确定不同维度节点的告警信息，包括：
42.获取指定时间段的多组运行数据；
43.根据所述多组运行数据和预设阈值，确定不同维度节点的异常运行数据；
44.根据所述异常运行数据和所述多组运行数据，确定不同维度节点的异常比例；
45.根据所述异常比例和所述预设告警策略，生成不同维度节点的告警信息。
46.作为可选地，所述根据所述异常比例和所述预设告警策略，生成不同维度节点的告警信息，包括：
47.当所述异常比例小于第一阈值时，不生成告警信息；
48.当所述异常比例在所述第一阈值和第二阈值之间时，生成第一告警信息；
49.当所述异常比例大于所述第二阈值时，生成第二告警信息，其中所述第一阈值小于所述第二阈值。
50.另一方面，本文还提供一种基于图数据的业务监控装置，所述装置包括：
51.历史日志数据获取模块，用于获取针对目标业务的历史日志数据；
52.关联关系提取模块，用于根据所述历史日志数据，提取获得所述目标业务交易链路中不同维度节点的关联关系；
53.图数据生成模块，用于根据所述关联关系生成不同维度节点的关联关系图数据；
54.可视化模型构建模块，用于根据所述图数据，构建生成所述目标业务交易链路中不同维度节点的可视化监控模型；
55.监控告警模块，用于根据所述可视化监控模型，结合预设告警策略，对所述目标业务的运行数据进行监控告警。
56.另一方面，本文还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述所述的方法。
57.最后，本文还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如上述所述的方法。
58.采用上述技术方案，本文所述的一种基于图数据的业务监控方法、装置、设备及存储介质，通过目标业务的历史日志数据，提取得到所述目标业务交易链路中不同维度的关联关系，并将所述关联关系通过可视化监控模型进行展示，从而解决了现有监控系统只能实现单个应用的指标监控，实现了从业务层次监控交易链路上不同维度的可视化监控，提高了故障定位的效率，从而提高了业务监控的效率。
59.为让本文的上述和其他目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附图式，作详细说明如下。
附图说明
60.为了更清楚地说明本文实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本文
等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本文的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、装置、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
93.现有技术中，对业务系统的监控主要是以单个应用的运行进行监控，考虑的是应用独立运行时的故障问题。由于业务运行是以交易链路上的应用的执行为基础的，当该业务运行出现故障时，链路上某环节报警，从而导致上游应用层层报警，在对故障定位时，是对业务交易链路上的应用逐个排除，难以精确快速定位问题根源。
94.为了解决上述问题，本说明书实施例提供一种业务监控方法，所述方法基于图数据实现的，如图1所示，为所述方法的实施环境示意图，可以包括目标业务10、服务器20和监控装置30，所述目标业务10可以为业务系统中任一业务，所述目标业务10执行时的日志信息存储在所述服务器20中，所述监控装置30通过获取所述服务器20中所述目标业务10的日志信息，提取得到所述目标业务交易链路中不同维度节点的关联关系，然后基于该关联关系构建生成所述目标业务交易链路中不同维度节点的可视化监控模型，从而根据建立的可视化监控模型进行所述目标业务的实时监控。本文通过对目标业务中不同维度节点都进行实时的监控，可以快速准确的对故障进行定位，提高了监控的效率。
95.所述服务器20能够实现日志信息的存储和提取，可以为具有具体硬件结构的实体装置，可以为能够实现相应存储和提取功能的软体结构，在一些其他实施例中，所述服务器20也可以为分布式服务器，在本说明书实施例不做限定。
96.具体地，本文实施例提供了一种基于图数据的业务监控方法，能够提高业务监控的效率。图2是本文实施例提供的一种基于图数据的业务监控方法的步骤示意图，本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或装置产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行。具体的如图2所示，所述方法可以包括：
97.s101：获取针对目标业务的历史日志数据；
98.s102：根据所述历史日志数据，提取获得所述目标业务交易链路中不同维度节点的关联关系；
99.s103：根据所述关联关系生成不同维度节点的关联关系图数据；
100.s104：根据所述图数据，构建生成所述目标业务交易链路中不同维度节点的可视化监控模型；
101.s105：根据所述可视化监控模型，结合预设告警策略，对所述目标业务的运行数据进行监控告警。
102.可以理解为，本说明书实施例通过对所述目标业务的历史日志数据进行分析，确定所述目标业务交易链路中不同维度节点的关联关系，所述不同维度节点可以为不同粒度的节点，比如应用层面，微服务层面等，通过确定不同维度节点的关联关系就可以得到所述目标业务交易链路中的业务功能实现的执行关系，从而实现对每一维度中节点的精准监
控。然后通过确定的关联关系生成不同维度节点的关联关系图数据，并基于所述图数据构建所述目标业务交易链路中不同维度节点的可视化监控模型，从而实现所述目标业务不同维度节点的可视化监控，并根据需要在不同的维度设置不同的告警策略，从而能够实现故障的准确快速定位，提高了监控的效率和可靠性。
103.所述历史日志数据可以为所述目标业务运行成功的历史日志数据，这样可以确保所述历日志数据中的信息都是可靠的信息，保证了提取信息的准确性。
104.所述关联关系可以为同一维度不同节点之间的关系，比如互访关系(执行时序)、调用关系等，也可以为不同维度之间节点的调用关系、从属关系等。
105.在一些实施例中，一笔业务的交易链路从发起到结束会流经若干个应用，所述业务可以为例如快捷支付、银证转账等银行金融业务。为了实现单笔银证转账交易，会流经交易链路上若干个应用，每个应用负责实现不同的功能，相互协作完成一笔交易，其中包括不同应用的互访关系或调用关系；同时，一个应用会为多个不同的业务提供支持，从而业务与应用之间会形成一种多对多的对应关系，因此，所述不同维度节点包括目标业务交易链路中应用、微服务集群、微服务、容器和数据库的一部分或全部。
106.其中，所述目标业务交易链路需要多个应用配合协作来实现，每个应用可以包括至少一个微服务集群来实现具体的单一功能，而每个微服务集群又能进一步的分成多个微服务，每个微服务在自己的进程中运行，聚焦单一的业务能力，并使用轻量级机制进行通信，从而实现了从宏观到微观的交易链路的提取。
107.在每个微服务功是围绕业务功能构建的，可以通过全自动部署机制独立部署，微服务不需要集中式管理，可以用不同的编程语言编写，并使用不同的数据存储技术。因此微服务的功能实现需要依赖其他微服务，假设微服务a依赖于微服务b和微服务c，而微服务b和微服务c有可能继续依赖于其他微服务，这样一条调用链上，如果某个微服务不可用或者延迟较高，则会导致调用微服务a的请求被堵住，占用系统的cpu、io等资源。当该类请求越来越多，占用的系统资源越来越多，会导致系统瓶颈出现，造成其他的请求也不可用，最终导致业务系统崩溃。因此本说明书实施例中业务系统通过容器技术(比如docker技术)可以提高不同微服务之间的自由融合和协作效率。
108.因此在微服务被调用执行时，可以确定不同容器之间的调用或互访关系，同时所述目标业务在运行过程中必然也涉及对数据的处理过程，本文还可以对数据库的调用情况进行监控，从而可以实现对所述目标业务全方面的可视化监控，提高监控的全面性和准确性。
109.在本说明书实施例中，如图3所示，所述根据所述历史日志数据，提取获得所述目标业务交易链路中不同维度节点的互访关系，包括：
110.s201：根据所述历史日志数据中的目标业务运行日志，确定所述目标业务中的全部应用及不同应用之间的互访关系；
111.s202：根据所述目标业务运行日志和所述全部应用，确定每个应用中微服务集群及不同微服务集群之间的互访关系；
112.s203：根据所述微服务集群，获取历史日志数据中的每个所述微服务集群对应的微服务调用日志；
113.s204：根据所述微服务调用日志，确定每个微服务集群中不同微服务之间的互访
关系；
114.s205：根据不同应用之间的互访关系、不同微服务集群之间的互访关系和所述不同微服务之间的互访关系，形成所述目标业务交易链路中不同维度节点的第一关联关系。
115.可以理解为，所述目标业务运行日志中包含了所述目标业务的应用信息，以及不同应用的执行关系，当然，一条日志信息涉及的信息可能比较少，不能完全展示所述目标业务上的全部应用，因此可以获取大量的运行日志，从而确保应用信息提取的完整性。
116.所述互访关系可以为不同应用之间的执行时序，即所述目标业务交易链路上不同功能实现的先后顺序。
117.进一步地，根据所述历史日志数据中的目标业务运行日志，确定所述目标业务中的全部应用及不同应用之间的互访关系，包括：
118.从所述目标业务运行日志中提取获得业务运行的源地址和目的地址；
119.根据所述源地址和所述目的地址，确定所述目标业务中的全部应用及不同应用之间的互访关系。
120.其中所述源地址和所述目的地址可以为不同服务器之间的互访关系，即通过源地址对应服务器方位目的地址对应的服务器，而每个服务器都对应这相应的应用，因此通过确定源地址和所述目的地址就能确定不同的应用以及不同应用之间的互访关系。
121.在一些其他实施例中，也可以有其他的方式确定不同的应用，比如通过分词(比如jieba工具)方式确定所述运行日志中的每个关键词，根据所述关键词确定相应的应用，也可以直接通过关键字提取的方式直接确定相应的应用。具体的确定方式在本说明书不做限定。
122.在确定全部应用时，即可进一步确定每个应用下的微服务集群，进而确定同一应用下的不同微服务集群的互访情况，这样就可以建立应用
‑
微服务集群的两级关联关系。
123.示例性地，比如银证转账交易，通过收集其运行成功的运行日志，例如一类单条日志数据如下：{"service":"ppsa.personal pay acs
‑
com.icbc.stars.transaction.common.commonservice__1_0_0","method":"execute","application":"f
‑
prsa","service_group":"ppsa_ac","provider":"1.1.1.1:35060","consumer":"2.2.2.2","success":4,"failure":0,"max_concurrent":2,"elapsed":156,"max_elapsed":46,"timeout":0,"execute_limit":0,"exhaust":0,"unkown":0,"node_active":3,"no_pr ovider":0,"consumer_group":"boom_ac","time":"2020
‑
09
‑
16t14:27:44.000z","type":"consumer","activate_percent":0.0}；通过上述日志中可以确定consumer 2.2.2.2访问了provider 1.1.1.1，可以得到2.2.2.2所在应用与1.1.1.1所在应用的互访关系，通过大量收集该银证转账交易链路业务中日志，形成多组源端ip所在应用和目的端ip互访，进而形成某一具体交易链路中应用互访关系。进一步地，上述日志中consumer 2.2.2.2访问了provider 1.1.1.1，取该日志中的“service_group”字段和“consumer_group”字段，即可确定该应用下不同微服务集群中的互访关系，即service_group对应的微服务集群和consumer_group对应的微服务集群。
124.具体地，如图4所示，为通过运行日志提取得到的银证转账交易中应用互访关系示意图，图中不同应用之间的连线表示它们之间的互访或调用关系，其中f5和slb(server load balance)均为服务器负载均衡，可以实现银证转账交易中的负载均衡，boom为银联转
账接入层，用于连接银联转账服务，nos为存储数据库，用于获取转账相关的数据，hsm为加密机，用于对数据进行加密处理，atp为客户协议查询，用于确定用户是否签署相关协议，以进行后续的个人账户的结算业务，pras(personal retail application system)为个人金融业务，用于对个人金融业务提供结算服务，dsr网关用于将boom和prsa的相关数据传输至主机中，主机中的主机服务交付实现数据的传输转移，pras个人金融是对接收到的数据进行个人金融业务的结算工作，通过上述应用之间的协作配合完成了针对个人金融业务的银证转账结算。
125.进一步地，通过已经确定的微服务集群，来获取微服务调用日志，进而分析得到微服务集群下的多个微服务的互访关系，示例性地，微服务调用日志如下：{"spanname":"com.atp.tx.channel.services.payprechkchanservinf__1_0/serve","traceid":"6074fd22d1c6c88f581c3b7ca4d8f5eb","spanid":"ab41925a07eaebc2","spanmatchid":null,"timestamp":"1618279714092173","createtime":null,"duration":33470,"appname":"f
‑
boom
‑
ac
‑
online","monitorconfbean":null,"parentid":"581c3b7ca4d8f5eb","durationstr":"33.470ms"。提取其中的parentid字段和spanid字段，parentid字段即为父节点，spanid即为子节点，通过大量收集该银证转账交易链路业务中此类日志，形成微服务调用链的互访关系。
126.在确定所述目标业务交易链路中不同维度节点的第一关联关系的基础上，还可以进一步的确定更小粒度节点的互访或调用关系，作为可选地，如图5所示，所述根据所述历史日志数据，提取获得所述目标业务交易链路中不同维度节点的关联关系，还包括：
127.s301：根据所述微服务，获取历史日志数据中的与所述微服务对应的数据接口调用日志；
128.s302：根据所述数据接口调用日志，确定所述微服务和所述容器的对应关系，以及不同容器之间的互访关系；
129.s303：获取历史日志数据中的所述容器对应的数据抓取日志；
130.s304：根据所述数据抓取日志，确定所述容器和所述数据库的对应关系；
131.s305：根据所述微服务和所述容器的对应关系、不同容器之间的互访关系和所述容器和所述数据库的对应关系，确定所述目标业务交易链路中不同维度节点的第二关联关系。
132.可以理解为，所述微服务和所述容器的包含关系可以通过数据接口调用日志来确定，通过容器实现对应微服务的业务功能，因此在本说明书业务系统中通过提前进行容器技术的配置，使得每个微服务的功能实现都能对应到一个容器。容器被调用时会通过相应的接口接收调用指令，因此可以通过所述数据接口调用日志获取所述微服务和所述容器的对应关系，进而分析得到不同容器之间的互访关系。
133.进一步地，在容器实现相应微服务功能的同时，还可以通过数据抓取日志确定数据库和容器的互访关系，也可以理解为容器和数据库的连接关系，在进行数据抓取时是通过在交换机上部署的抓包设备抓取流量包中的源地址和目的地址，该源地址和目的地址可以理解为数据库地址，因此通过获取大量的数据抓取日志可以提取得到全部的容器和数据库的互访关系。
134.通过上述步骤得到的所述目标业务交易链路中不同维度节点的第一关联关系和
第二关联关系，即可确定所述目标业务交易链路中不同维度节点的关联关系，进一步实施例中，所述根据所述关联关系生成不同维度节点的关联关系图数据，包括：
135.根据所述关联关系，生成不同维度节点的关联关系文本数据；
136.根据所述文本数据，转换生成不同维度节点的关联关系图数据。
137.所述关联关系文本数据能够直接表现不同维度节点的关联关系，但是对单个业务，其交易链路上的不同维度节点的数量和关联关系的复杂程度都比较高，当出现故障时也很难直接对故障进行定位，只通过文书形式很难有直观的感受，因此可以将所述文书数据转换成图数据形式，并通过图数据的形式进行存储和展示，比如可以采用节点
‑
关系的存储形式，文本数据转换成图数据的方式为文本转换常见的技术手段，在本说明书实施例不做限定。
138.进一步实施例中，在对文本数据转换之前还可以包括对文本数据的预处理过程，比如对文本数据进行清洗，通过去重、删除异常数据等方式获取优化后的文本数据，可以保证文本数据的可靠性和准确性。
139.进一步实施例中，在转换之后得到的图数据存储至所述图数据库(比如neo4j图数据库)中，比如可以采用节点
‑
关系的存储形式。
140.在获取所述目标业务交易链路上不同维度节点的图数据后，则可以进行可视化监控模型的构建，作为可选地，如图6所示，所述根据所述图数据，构建生成所述目标业务交易链路中不同维度节点的可视化监控模型，包括：
141.s401：构建基于多维度节点的可视化初始监控模型，所述可视化初始监控模型包括节点类型和节点关联属性；
142.s402：根据所述节点类型，确定每个维度节点对应的图数据，并将所述图数据加载至所述可视化初始监控模型；
143.s403：根据所述节点关联属性，对加载图数据后的可视化初始监控模型进行配置，以得到构建完成的所述目标业务交易链路中不同维度节点的可视化监控模型。
144.其中，所述节点类型可以为不同维度的节点类型，所述可视化监控模型可以根据不同维度节点设置的多层展示层，每层展示层包括同一维度的节点及其关联关系，不同的展示层可以建立相应的关联关系，比如通过连线等方式，本文通过从不同维度直观展示目标业务一笔交易链路中的不同层级的运行状况，进而满足运维人员不同层次的需求。例如分别是一笔交易链路中流经应用互访关系，微服务集群之间的互访关系，微服务调用链互访关系，微服务调用链中容器发起方与容器被调用方的互访关系；在逻辑展示上由粗至细，逐层向下展示。
145.所述节点关联属性包括节点类型标识、图数据形状以及互访标识。比如不同的节点类型采用不同的颜色、样式等，从而能快速区分不同节点的运行状况，所述图数据形状可以为每层展示层的表现状态，进一步提高了可视化的辨识度，所述互访表示可以为不同节点之间的关联关系，可以通过不同颜色、粗细等形态的连线表示，这样可以实现针对性的监控。解决了现有的监控系统只能实现单应用的指标监控，无法实现对一类业务交易链路可视化的问题，并且相较于现有的依赖于传统监控平台运维方式，简化了现有反复查询全息监控平台的故障定位流程，直接通过可视化监控模型中就能直接进行故障定位，减轻了运维人员运维压力。
146.在获得可视化监控模型的基础上，就能对所述目标业务运行情况进行实时监控，作为可选地，如图7所示，所述根据所述可视化监控模型，结合预设告警策略，对所述目标业务的运行数据进行监控告警，包括：
147.s501：实时获取所述目标业务的运行数据，所述运行数据至少包括以下内容之一：不同维度节点运行时长、不同维度节点运行cpu使用率、数据库调用耗时；
148.s502：根据所述运行数据和预设告警策略，确定不同维度节点的告警信息；
149.s503：根据所述告警信息，在所述可视化监控模型中显示相应的告警提示。
150.可以理解为，针对不同的节点可以设置不同的监控指标，这样可以实现不同维度节点的独立监控，提高了控制的准确性和全面性。当然也可以只对部分重要节点做监控，可以减少全量监控带来的负载压力，提高了监控的稳定性。
151.在实际工作中可以按照指定周期采集运行数据，比如3分钟或5分钟一组数据等，这样可以减少实时采集的数据存储压力，在采集过后即可进行异常点的确定，或者采集一定数量(或在指定时间段内)的数据在进行统一分析，本说明书实施例不做限定。
152.示例性地，比如针对应用层面设置监控指标，不同的应用可以设置不同的监控指标，包括该应用运行时间阈值和cpu使用率阈值和数据库调用耗时阈值，当在该应用的运行数据中至少有一项指标超过了相应阈值，则表示该应用处于异常状态，需要给出相应的告警提示。在告警时，可以直接在所述可视化监控模型中的节点位置进行告警，可以便于运维人员快速确定异常位置，从而提高对故障解决的时效性。当然也可以设置单独的告警板块，可以实现告警的集中展示，便于运维人员收集告警信息。
153.虽然针对单一目标业务涉及到的节点之间的调用较清晰，但是针对全业务系统监控时，应该对每个业务都进行可视化监控展示，不同业务之间也存在节点共用的情况，因此对整个业务系统的监控会很复杂，在告警提示时采用单个采样点进行告警的方式会造成告警过于频繁，影响运维人员判断，因此所述根据所述运行数据和预设告警策略，确定不同维度节点的告警信息，包括：
154.获取指定时间段的多组运行数据；
155.根据所述多组运行数据和预设阈值，确定不同维度节点的异常运行数据；
156.根据所述异常运行数据和所述多组运行数据，确定不同维度节点的异常比例；
157.根据所述异常比例和所述预设告警策略，生成不同维度节点的告警信息。
158.通过设置指定时间段的方式进行告警，可以确保告警的时效性，同时也能实现对多个业务同时监控，由于在指定时间段内包括多个采样点，因此通过采样点异常情况的分析确定是否进行告警，比如当异常点数较多时，则表示相应指定时间段内的节点异常概率较高，可以进行告警提示。通过异常比例进行告警可以保证告警的可靠性，同时也能减少短暂冲高告警的概率，进一步保证了告警的可信度。
159.进一步实施例中，所述根据所述异常比例和所述预设告警策略，生成不同维度节点的告警信息，包括：
160.当所述异常比例小于第一阈值时，不生成告警信息；
161.当所述异常比例在所述第一阈值和第二阈值之间时，生成第一告警信息；
162.当所述异常比例大于所述第二阈值时，生成第二告警信息，其中所述第一阈值小于所述第二阈值。
163.可以理解为，异常比例能够反映相应节点的异常状况，其异常比例较大时，则表示相应时间段内节点异常次数较多，需要进行较高程度的告警，以提高运维人员的重视程度。
164.示例性地，在指定时间段内采集的采样点为100个，通过上述步骤中的监控指标对每个采样点的异常情况进行分析，从而确定该指定时间段内的异常比例，假设所述第一阈值为20％，所述第二阈值为60％，通过所述异常比例与20％和60％进行比较来确定不同的告警级别，作为可选地，所述第一告警信息可以为短信提醒、邮件提醒、以及可视化监控模型中节点的颜色变化等，所述第二告警信息可以为语音提醒以及可视化监控模型中节点的高亮闪烁等。其中所述第二告警信息的强度大于所述第二告警信息的强度。具体的告警方式在本说明书不做限定。
165.本文提供的基于图数据的业务监控方法，通过目标业务的历史日志数据，提取得到所述目标业务交易链路中不同维度的关联关系，并将所述关联关系通过可视化监控模型进行展示，在目标业务运行时通过其运行数据和预设告警策略实现了不同维度节点的监控，并在可视化监控模型进行告警，从而解决了现有监控系统只能实现单个应用的指标监控，实现了从业务层次监控交易链路上不同维度的可视化监控，提高了故障定位的效率，从而提高了业务监控的效率。
166.基于同一发明构思，本文还提供一种基于图数据的业务监控装置，如图8所示，所述装置包括：
167.历史日志数据获取模块100，用于获取针对目标业务的历史日志数据；
168.关联关系提取模块200，用于根据所述历史日志数据，提取获得所述目标业务交易链路中不同维度节点的关联关系；
169.图数据生成模块300，用于根据所述关联关系生成不同维度节点的关联关系图数据；
170.可视化模型构建模块400，用于根据所述图数据，构建生成所述目标业务交易链路中不同维度节点的可视化监控模型；
171.监控告警模块500，用于根据所述可视化监控模型，结合预设告警策略，对所述目标业务的运行数据进行监控告警。
172.通过上述装置所取得的有益效果和上述方法所取得的有益效果一致，在本说明书实施例不做赘述。
173.需要说明的是，本说明书实施例提供的一种基于图数据的业务监控方法及装置可用于金融领域在业务系统运维监控策略上，也可以用于除金融领域之外的任意领域，本说明书实施例提供的一种基于图数据的业务监控方法及装置的应用领域不做限定。
174.如图9所示，为本文实施例提供的一种计算机设备，所述计算机设备902可以包括一个或多个处理器904，诸如一个或多个中央处理单元(cpu)，每个处理单元可以实现一个或多个硬件线程。计算机设备902还可以包括任何存储器906，其用于存储诸如代码、设置、数据等之类的任何种类的信息。非限制性的，比如，存储器906可以包括以下任一项或多种组合：任何类型的ram，任何类型的rom，闪存设备，硬盘，光盘等。更一般地，任何存储器都可以使用任何技术来存储信息。进一步地，任何存储器可以提供信息的易失性或非易失性保留。进一步地，任何存储器可以表示计算机设备902的固定或可移除部件。在一种情况下，当处理器904执行被存储在任何存储器或存储器的组合中的相关联的指令时，计算机设备902
可以执行相关联指令的任一操作。计算机设备902还包括用于与任何存储器交互的一个或多个驱动机构908，诸如硬盘驱动机构、光盘驱动机构等。
175.计算机设备902还可以包括输入/输出模块910(i/o)，其用于接收各种输入(经由输入设备912)和用于提供各种输出(经由输出设备914))。一个具体输出机构可以包括呈现设备916和相关联的图形用户接口(gui)918。在其他实施例中，还可以不包括输入/输出模块910(i/o)、输入设备912以及输出设备914，仅作为网络中的一台计算机设备。计算机设备902还可以包括一个或多个网络接口920，其用于经由一个或多个通信链路922与其他设备交换数据。一个或多个通信总线924将上文所描述的部件耦合在一起。
176.通信链路922可以以任何方式实现，例如，通过局域网、广域网(例如，因特网)、点对点连接等、或其任何组合。通信链路922可以包括由任何协议或协议组合支配的硬连线链路、无线链路、路由器、网关功能、名称服务器等的任何组合。
177.对应于图2
‑
图7中的方法，本文实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法的步骤。
178.本文实施例还提供一种计算机可读指令，其中当处理器执行所述指令时，其中的程序使得处理器执行如图2至图7所示的方法。
179.应理解，在本文的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本文实施例的实施过程构成任何限定。
180.还应理解，在本文实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
181.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本文的范围。
182.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
183.在本文所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。
184.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本文实施例方案的
目的。
185.另外，在本文各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
186.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本文的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本文各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read
‑
only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
187.本文中应用了具体实施例对本文的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本文的方法及其核心思想；同时，对于本领域的一般技术人员，依据本文的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本文的限制。