CN109254901A - 一种指标监测方法及系统 - Google Patents

Abstract

本发明提供一种指标监测方法及系统，涉及信息技术领域。该指标监测方法包括：生成目标应用系统的服务拓扑图；根据所述服务拓扑图和监测指标，显示所述服务拓扑图中应用服务的当前状态。本发明实施例实现针对应用服务的拓扑图状态显示，更便于用户对应用服务的监控，大幅节省运维人员的工作量，提高了目标应用系统的运行稳定性。

Description

一种指标监测方法及系统

技术领域

本发明涉及信息技术大数据处理领域，尤其涉及一种指标监测方法及系统。

背景技术

随着IT、互联网、移动互联网的持续发展，企业中各种业务IT系统得到越来越多的重视，而日志监测指标作为表示企业业务IT系统运行状况的必要参数，就需要得到及时的监控，随之而来的，日志数据的处理则成了企业业务IT系统运维的一个基本工作。

然而业务IT系统的业务量的爆发式增长，服务的数量不断增加，企业业务IT系统运行过程中产生的日志数据量也大规模增加，服务间的交互关系也变得异常复杂。

目前监测系统通常针对分布式服务中的单个服务或单台计算机进行监控，在业务请求异常时，需要人工确定相应业务请求的各服务之间的调用关系，然后再根据调用关系具体分析业务请求异常原因，处理效率较低。

发明内容

本发明实施例提供一种指标监测方法及系统，以实现针对应用服务的拓扑图状态显示，更便于用户对应用服务的监控，大幅节省运维人员的工作量，提高了目标应用系统的运行稳定性。

为达到上述目的，本发明的实施例提供一种指标监测方法，所述方法包括：

生成目标应用系统的服务拓扑图；

根据所述服务拓扑图和监测指标，显示所述服务拓扑图中应用服务的当前状态。

其中，所述生成目标应用系统的服务拓扑图的步骤，包括：

根据用户在所述目标应用系统的服务拓扑图绘制界面的输入，生成所述服务拓扑图；或者

通过采集目标应用系统的组织架构生成服务拓扑图。

其中，所述生成目标应用系统的服务拓扑图的步骤，包括：

响应于用户对服务拓扑图的编辑输入，删除或添加对应的应用服务到服务拓扑图。

其中，所述通过采集目标应用系统的组织架构生成服务拓扑图的步骤，包括：

根据所述目标应用系统采集的数据，得到生成所述服务拓扑图所需的目标信息；

根据所述目标信息，确定服务拓扑图的布局信息；

根据所述布局信息，生成服务拓扑图。

其中，所述目标信息包括：应用服务信息，机器信息，以及各个应用服务之间的调用关系和数据流向；

所述根据所述目标应用系统采集的数据，得到生成所述服务拓扑图所需的目标信息的步骤，包括：

提取采集到的数据中的应用服务信息和机器信息；

在应用服务的服务请求中添加标识信息；

根据所述服务请求的处理数据，获得所述标识信息的跟踪数据；

根据所述跟踪数据，得到各个应用服务之间的调用关系和数据流向。

其中，所述标识信息包括：服务请求标识和服务过程信息，所述服务过程信息用于表明当前应用服务对所述服务请求的处理过程；

所述根据所述跟踪数据，得到各个应用服务之间的调用关系和数据流向的步骤，包括：

获取所述跟踪数据中同属于一个服务请求标识的服务过程信息；

根据所述服务过程信息进行排序，确定各个应用服务之间的调用关系和数据流向。

其中，所述根据所述目标信息，确定服务拓扑图的布局信息的步骤，包括：

根据所述目标信息，统计节点信息和节点间连线信息；

基于交叉最小化规则计算节点坐标，并基于空间利用率最大化规则布局节点间的连线，得到所述布局信息。

其中，在所述生成目标应用系统的服务拓扑图的步骤之前，所述方法还包括：

根据用户在用户界面的输入，确定目标应用系统以及所述目标应用系统的应用服务。

其中，所述应用服务包括以下至少之一：计算引擎服务、存储服务、数据存储及搜索服务、数据库服务、消息队列服务、配置服务、监控服务、数据采集服务、数据查询服务和数据处理服务。

其中，所述监测指标是对应所述应用服务设置的。

其中，所述根据所述服务拓扑图和监测指标，显示所述服务拓扑图中应用服务的当前状态的步骤，包括：

基于预设的多级阈值范围，由所述监测指标确定当前各个应用服务的目标阈值范围，并采用所述目标阈值范围对应的显示方式显示应用服务。

其中，所述根据所述服务拓扑图和监测指标，显示所述服务拓扑图中应用服务的当前状态的步骤，还包括：

基于所述监测指标，在所述服务拓扑图中呈现应用服务的健康状态。

其中，在所述显示所述服务拓扑图中应用服务的当前状态的步骤之后，所述方法还包括：

基于用户选择的目标节点，显示所述目标节点的节点信息，其中所述节点信息包括所述目标节点对应应用服务的类别、归属应用系统和机器项；

基于用户选择的目标机器项，显示与所述目标机器项对应的监测指标的监控数据。

其中，所述方法还包括：

响应于用户基于所述目标节点和/或所述目标机器项的输入，执行对应处理；其中，所述处理包括以下至少之一：

调整监测指标；

显示所述目标机器项在指定时长内的状态；

显示指定监测指标的数据；

显示指定日志数据；

以及，分析异常原因和制定异常处理方案。

本发明实施例还提供一种指标监测系统，所述指标监测系统包括：

生成模块，用于生成目标应用系统的服务拓扑图；

第一显示模块，用于根据所述服务拓扑图和监测指标，显示所述服务拓扑图中应用服务的当前状态。

其中，所述生成模块还用于：

根据用户在所述目标应用系统的服务拓扑图绘制界面的输入，生成所述服务拓扑图；或者

通过采集目标应用系统的组织架构生成服务拓扑图。

其中，所述生成模块还用于：

响应于用户对服务拓扑图的编辑输入，删除或添加对应的应用服务到服务拓扑图。

其中，所述生成模块包括：

处理子模块，用于根据所述目标应用系统采集的数据，得到生成所述服务拓扑图所需的目标信息；

确定子模块，用于根据所述目标信息，确定服务拓扑图的布局信息；

生成子模块，用于根据所述布局信息，生成服务拓扑图。

其中，所述目标信息包括：应用服务信息，机器信息，以及各个应用服务之间的调用关系和数据流向；

所述处理子模块包括：

信息提取单元，用于提取采集到的数据中的应用服务信息和机器信息；

添加单元，用于在应用服务的服务请求中添加标识信息；

第一处理单元，用于根据所述服务请求的处理数据，获得所述标识信息的跟踪数据；

第二处理单元，用于根据所述跟踪数据，得到各个应用服务之间的调用关系和数据流向。

其中，所述标识信息包括：服务请求标识和服务过程信息，所述服务过程信息用于表明当前应用服务对所述服务请求的处理过程；

所述第二处理单元包括：

获取子单元，用于获取所述跟踪数据中同属于一个服务请求标识的服务过程信息；

确定子单元，用于根据所述服务过程信息进行排序，确定各个应用服务之间的调用关系和数据流向。

其中，所述确定子模块包括：

统计单元，用于根据所述目标信息，统计节点信息和节点间连线信息；

第三处理单元，用于基于交叉最小化规则计算节点坐标，并基于空间利用率最大化规则布局节点间的连线，得到所述布局信息。

其中，所述系统还包括：

确定模块，用于根据用户在用户界面的输入，确定目标应用系统以及所述目标应用系统的应用服务。

其中，所述应用服务包括以下至少之一：计算引擎服务、存储服务、数据存储及搜索服务、数据库服务、消息队列服务、配置服务、监控服务、数据采集服务、数据查询服务和数据处理服务。

其中，所述监测指标是对应所述应用服务设置的。

其中，所述第一显示模块还用于：

基于预设的多级阈值范围，由所述监测指标确定当前各个应用服务的目标阈值范围，并采用所述目标阈值范围对应的显示方式显示应用服务。

其中，所述第一显示模块还用于：

基于所述监测指标，在所述服务拓扑图中呈现应用服务的健康状态。

其中，所述系统还包括：

第二显示模块，用于基于用户选择的目标节点，显示所述目标节点的节点信息，其中所述节点信息包括所述目标节点对应应用服务的类别、归属应用系统和机器项；

第三显示模块，用于基于用户选择的目标机器项，显示与所述目标机器项对应的监测指标的监控数据。

其中，所述系统还包括：

处理模块，用于响应于用户基于所述目标节点和/或所述目标机器项的输入，执行对应处理；其中，所述处理包括以下至少之一：

调整监测指标；

显示所述目标机器项在指定时长内的状态；

显示指定监测指标的数据；

显示指定日志数据；

以及，分析异常原因和制定异常处理方案。

本发明实施例还提供一种指标监测系统，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序；其中，所述处理器执行所述计算机程序时实现上述的指标监测方法中的步骤。

本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述的指标监测方法中的步骤。

本发明的上述技术方案的有益效果如下：

上述方案，针对服务拓扑图中节点对应的应用服务显示其当前状态，实现了应用服务的拓扑图状态显示，更便于用户对应用服务的监控，大幅节省运维人员的工作量，提高了目标应用系统的运行稳定性。

附图说明

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

图1为本发明实施例提供的指标监测方法的流程图之一；

图2为建立应用系统的界面示意图；

图3为编辑应用服务的界面示意图；

图4为新建服务拓扑图的界面示意图；

图5为服务拓扑图的绘制界面示意图；

图6为服务拓扑图的展示界面示意图；

图7为本发明实施例提供的指标监测方法的流程图之二；

图8为本发明实施例提供的指标监测系统的模块图。

具体实施方式

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

请参照图1，图1是本发明一实施例提供的指标监测方法的流程图，该指标监测方法，应用于指标监测系统，包括：

步骤101，生成目标应用系统的服务拓扑图；

步骤102，根据所述服务拓扑图和监测指标，显示所述服务拓扑图中应用服务的当前状态。

在该实施例中，服务拓扑图中的节点对应该目标应用系统的应用服务，节点间的连线则表示应用服务间的调用关系和数据流向。通过上述步骤，首先会生成目标应用系统的服务拓扑图，然后结合该服务拓扑图和监测指标，针对服务拓扑图中节点对应的应用服务显示其当前状态，来实现应用服务的拓扑图状态显示，更便于用户对应用服务的监控，大幅节省运维人员的工作量，提高了目标应用系统的运行稳定性。

其中，所述应用服务包括以下至少之一：计算引擎服务、存储服务、数据存储及搜索服务、数据库服务、消息队列服务、配置服务、监控服务、数据采集服务、数据查询服务和数据处理服务。

具体的，计算引擎服务包括组件：Spark(一种专为大规模数据处理而设计的快速通用的计算引擎)、Flink(一种分布式大数据处理的实时计算引擎)等；存储服务包括组件：HDFS(一种分布式文件系统)等；数据存储及搜索服务包括组件：搜索引擎ElasticSearch等；数据库服务包括组件：HBase(一种构建在HDFS上的分布式列存储系统)、MySQL(一种关系型数据库管理系统)、OpenTSDB(一种基于HBase的分布式、可伸缩的时间序列数据库)、Redis(一种键值数据库)等；消息队列服务包括组件：分布式发布订阅消息系统Kafka、可复用的企业消息系统RabbitMQ等；配置服务包括组件：Apollo(一种分布式配置系统)等；监控服务包括组件：Aitopo(一种拓扑图管理服务系统)、MoniMaker(一种监控配置前端界面系统)、monitor(一种监控配置接口服务系统)等；数据采集服务包括组件：Logstash(一种日志收集管理系统)、Ingest(一种采集点管理服务系统)、logagent(一种采集代理系统)等；数据查询服务包括组件：日志中心logcenter等；数据处理服务包括组件：Logstash(可用于数据解析)、logcenter(可用于数据统计)等。

需要知道的是，应用服务可以是系统默认的，例如可采用按类别归集实例，因此，所有的MySQL实例都归集到一个MySQL服务，该实例可以是一个具体的服务进程；应用服务也可以是用户自定义的，例如可按集群设置多个MySQL服务，因此，集群1的MySQL服务是MySQL1(可以有多个实例)，集群2的MySQL服务是MySQL2。

而且，由上述内容还知道的是，该实施例中，对应用服务的监测，针对生成的服务拓扑图，是结合监测指标来实现的。指标，用于衡量业务IT系统运营状况的参数，包括基于日志数据计算出来的指标数据(例如交易总量等)、系统直接采集来的指标数据(例如中央处理器CPU使用率等)和其他指标数据。具体的，指标包括公共指标：CPU使用率、内存使用率、磁盘占用率、运行状态(正常/异常)等。另外，指标还包括针对不同应用服务的特定指标，例如，数据库服务(对应组件：HBase)对应的指标还包括：分区服务运行状况(regionserver运行状况)；消息队列服务(对应组件：Kafka)对应的指标还包括：分区是否均匀(partition是否均匀)；数据存储及搜索服务(对应组件：ElasticSearch)对应的指标还包括：集群健康度、活跃节点数占比、分片是否平衡、平均请求(query+fetch)响应时长、单位时间写入速率；数据采集服务(对应组件：Logstash、Ingest、logagent)对应的指标还包括：监控数据的种类；数据处理服务(对应组件：Logstash、logcenter)对应的指标还包括：监控数据处理速度。因此，在该实施例中，可选地，所述监测指标是对应所述应用服务设置的。如此，对于已生成的服务拓扑图，即可按照监测指标对其中的应用服务进行监测。

当然，针对不同应用服务的监测指标可以是系统默认的，也可以是用户自定义的，即用户可编辑指标生成新的指标，如把多个指标进行组合。

应该知道的是，在该实施例中，一个应用系统对应一个服务拓扑图，即一个应用系统中节点及节点间连线是确定的，为满足对不同应用系统的监测需求，预先设置了多个应用系统，故，在步骤101之前，所述方法还包括：

根据用户在用户界面的输入，确定目标应用系统以及所述目标应用系统的应用服务。

这里，用户可基于用户界面，建立或选择应用系统作为目标应用系统，对应的，即可确定该目标应用系统的应用服务，从而针对目标应用系统生成服务拓扑图，以实现针对目标应用系统的应用服务监测的目的。当然，在目标应用系统确定后，应用服务可基于默认设置确定，又或者基于用户对该目标应用系统中应用服务的选择确定。同样的，该目标应用系统归属的应用域，可以是默认设置，也可以是用户自定义设置。

具体的，该实施例中用户界面可包括：应用系统建立界面、编辑应用服务界面和新建拓扑图界面等。对应于用户的监测需求，用户可预先建立监测的应用系统及其应用服务，需要从大到小建立(新建)：应用域(分组)-应用系统(可以是不同功能的系统)-机器(可以对应实体和/或虚拟主机、单机和/或分布式主机等)-应用服务。如图2所示，在应用系统建立的界面，根据用户输入分别创建了智能运维系统、多维指标分析系统和日志分析系统，之后进一步建立应用服务。以智能运维系统为例，可通过应用服务的编辑选项触发图3所示的编辑应用服务界面，来调整该服务部署的机器，同时在编辑机器界面内，可由机器的编辑选项调整在该机器部署的服务。当然上述两种编辑调整一种，则另一种可对应自动调整，在此不再赘述。在完成应用系统及其应用服务的建立后，就能够基于该应用系统和应用服务，触发图4所示的新建服务拓扑图界面，选择数据来源后就可生成对应的服务拓扑图。

此外，监测系统中可默认设置有应用域(分组)-应用系统(可以是不同功能的系统)-机器(可以对应实体和/或虚拟主机、单机和/或分布式主机等)-应用服务，此时，用户只需在图4所示的新建拓扑图界面上选择应用域、应用系统及数据来源，来生成对应的服务拓扑图。

此外，为适应不同用户对服务拓扑图的使用需求，在本发明的实施例中，步骤101包括：

根据用户在所述目标应用系统的服务拓扑图绘制界面的输入，生成所述服务拓扑图；或者

通过采集目标应用系统的组织架构生成服务拓扑图。

如此，监测系统不仅能够自动生成目标应用系统的服务拓扑图，还能够根据用户手动绘制生成该服务拓扑图。

可选地，步骤101包括：

响应于用户对服务拓扑图的编辑输入，删除或添加对应的应用服务到服务拓扑图。

这样，在生成目标应用系统的服务拓扑图的过程中，用户还能够根据对应用服务的监测需求，对服务拓扑图中的应用服务进行删除或添加。

具体的，在图4所示的新建拓扑图界面，不选择数据来源的情况下，点击确认按键后，会触发如图5所示的服务拓扑图绘制界面。在该服务拓扑图绘制界面可以查看、编辑拓扑图，左侧导航栏：包括选择的应用系统下的各应用服务。在该服务拓扑图绘制界面的编辑方式包括添加、删除应用服务等。用户可以通过拖拽的方式从左侧添加应用服务至右侧画布，及在应用服务之间建立连线手动绘制服务拓扑图，绘制结束后保存以完成该服务拓扑图的生成。当然，用户手动绘制拓扑图的话，要求对应用服务之间的调用关系很清楚，也可以通过采集的数据对所画的服务拓扑图进行验证，验证方式包括且不限于和采集的服务调用关系进行比对、和采集的数据流向进行比对。

而对于图4中选择数据来源，例如自动拓扑的情况下，监测系统会自动生成该应用系统对应的服务拓扑图。自动生成的服务拓扑图也可以显示在如图5所示的服务拓扑图绘制界面，此时的服务拓扑图为可编辑的，用户可以从系统自动生成的服务拓扑图中删除不关注的部分内容，选择一部分关注的内容进行保存。举例说明，根据责任划分，某用户(运维)只负责Kafka到MySql这部分(涉及日志数据收集及写入数据库)，在生成服务拓扑图时就可以删除Kafka到MySql以外的服务节点(例如ingest)。这样生成的服务拓扑图只包含Kafka到MySql的部分。保存以完成该服务拓扑图的生成。当然，该实施例中对服务拓扑图的编辑，不影响系统真实的组织架构。另外，自动生成的服务拓扑图也可以仅进行展示，如图6所示，若需要进行编辑，需点击“进入编辑模式”按键来触发服务拓扑图绘制界面。

可选地，所述通过采集目标应用系统的组织架构生成服务拓扑图的步骤，包括：

根据所述目标应用系统采集的数据，得到生成所述服务拓扑图所需的目标信息；

根据所述目标信息，确定服务拓扑图的布局信息；

根据所述布局信息，生成服务拓扑图。

在该实施例中，监测系统能够调用接口，把目标应用系统的组织架构采集过来自动生成服务拓扑图。因此，在根据目标应用系统采集的数据得到生成服务拓扑图所需的目标信息后，进一步可由该目标信息确定服务拓扑图的布局信息，继而生成服务拓扑图。

其中，所述目标信息包括：应用服务信息，机器信息，以及各个应用服务之间的调用关系和数据流向；

如图7所示，所述根据所述目标应用系统采集的数据，得到生成所述服务拓扑图所需的目标信息的步骤，包括：

步骤701，提取采集到的数据中的应用服务信息和机器信息；

步骤702，在应用服务的服务请求中添加标识信息；

步骤703，根据所述服务请求的处理数据，获得所述标识信息的跟踪数据；

步骤704，根据所述跟踪数据，得到各个应用服务之间的调用关系和数据流向。

这里，目标信息主要包括：应用服务信息，例如：应用服务的名称、类别、备注等；机器信息，如服务实例的机器IP地址、端口等；以及各个应用服务之间的调用关系和数据流向。对于应用服务信息和机器信息，可由采集的数据提取获得，而为了掌握各个应用服务之间的调用关系和数据流向，则要在服务请求中添加标识信息，由该服务请求的处理数据来获得标识信息的跟踪数据，进而得到各个应用服务之间的调用关系和数据流向。

当然，在该实施例中，上述提取应用服务信息和机器信息的步骤与得到各个应用服务之间的调用关系和数据流向的步骤并不限定先后，可先执行步骤701，然后执行步骤702-704；又或者，先执行步骤702-704，然后执行步骤701；又或者，两者并行。

这里，对于提取的应用服务信息如服务名称，机器信息：如IP地址和端口等，会将机器信息更新至数据库(例如MySQL数据库、PostgreSql数据库、Oracle数据库、SqlServer数据库)，具体的会录入到对应的表，即机器的表；服务实例信息更新至数据库，也录入到对应的表，即服务实例的表，表中含有应用域、应用系统、机器字段；服务信息(某类别的服务)更新至数据库，录入到对应的表，即服务的表，表中包含应用域、应用系统字段。

另外，考虑到客户端/服务器端调用请求会调用多次，在该实施例中，会对采集的数据去重，如此，仅需要一次数据既可获知调用关系和数据流向，也不会在数据库中录入重复数据。

其中，所述标识信息包括：服务请求标识和服务过程信息，所述服务过程信息用于表明当前应用服务对所述服务请求的处理过程；

所述根据所述跟踪数据，得到各个应用服务之间的调用关系和数据流向的步骤，包括：

获取所述跟踪数据中同属于一个服务请求标识的服务过程信息；

根据所述服务过程信息进行排序，确定各个应用服务之间的调用关系和数据流向。

这里，同一请求在所有应用服务中的服务请求标识traceid是唯一的，服务过程信息span用于表明当前应用服务对该服务请求的处理过程，span记录每个应用服务对该请求的处理过程。如此，在添加标识信息traceid和span到服务请求中后，随着客户端/服务器端/应用服务间调用请求并在调用过程(即client invoke request)中传递该服务请求的跟踪数据，收集跟踪数据，根据跟踪数据将同属于一个服务请求标识的服务信息进行排序，既可确定各个应用服务之间的调用关系和数据流向。例如，收集span，由监测系统的跟踪装置如跟踪服务器，用traceid把span串起来，每一个span是一个调用过程；具体包括：整合同属一个traceid的span、排序span、计算各个应用服务之间的依赖关系，得出应用服务间的调用关系和数据流向。

在该实施例中，跟踪实现可由侵入式Zipkin或非侵入式Pinpoint追踪分布式应用。Zipkin方案追踪请求的处理过程，需要修改代码，即需要在请求中手动地插入标识信息，该方案适用各种编程语言。Pinpoint方案采用javaagent技术，修改Java程序的运行指令，把自动生成traceid、span的代码插入到Java程序中，可以自动实现收到请求后在请求中插入标识信息。

具体的，Zipkin方案，步骤如下：(1)基于检测到的用户界面的操作，用户发出请求(HTTP、MQ等格式的消息)即服务请求。(2)服务器收到请求后在请求中插入标识信息，即对请求进行处理：插入traceid(同一个请求在所有服务中的唯一标识)、服务过程信息(即span)，所述span是每个应用服务对该请求的处理过程。(3)传递标识信息，客户端/服务器端/应用服务调用请求并在调用过程(即client invoke request)中传递标识信息。(4)收集标识信息的跟踪数据，例如收集span，发送到跟踪服务器，汇聚成调用图(用traceid把span串起来，每一个span是一个调用过程；具体包括：整合同属一个traceid的span、排序span、计算各个服务之间的依赖关系)，所述调用图即各个应用服务之间的调用关系和数据流向。

Pinpoint方案，步骤如下：(1)用户发出请求即服务请求。(2)服务器收到请求后在请求中插入标识信息，即对请求进行处理：插入traceid(同一个请求在所有服务中的唯一标识)、服务过程信息(即span)，所述span是每个应用服务对该请求的处理过程。Pinpoint方案采用javaagent技术，修改Java程序的运行指令，把自动生成traceid、span的代码插入到Java程序中，可以自动实现该步骤(2)。(3)传递标识信息，客户端/服务器端/应用服务调用请求并在调用过程(即client invoke request)中传递标识信息，(4)收集标识信息的跟踪数据，例如收集span，发送到跟踪服务器，汇聚成调用图(用traceid把span串起来，每一个span是一个调用过程)，所述调用图即各个应用服务之间的调用关系和数据流向。Pinpoint属于非侵入式，它采用javaagent技术，在应用服务启动时需要通过传递参数(即传递扩展包)例如"-javaagent:<path/to/pinpoint-bootstrap-***.jar>"，以使用javaagent。这样在生成调用图的过程中，某些方法的执行过程就会被监控(即服务的调用过程)、并注入额外的数据(例如插入span、traceid等)。

在得到目标信息后，既可进一步确定服务拓扑图的布局信息。可选地，所述根据所述目标信息，确定服务拓扑图的布局信息的步骤，包括：

根据所述目标信息，统计节点信息和节点间连线信息；

基于交叉最小化规则计算节点坐标，并基于空间利用率最大化规则布局节点间的连线，得到所述布局信息。

这里由目标信息就能够统计出该服务拓扑图的节点信息例如节点数量和节点间连线信息，之后，基于交叉最小化规则计算节点坐标，基于空间利用率最大化规则布局节点间的连线，得到交叉点最少、空间利用率最高的布局，从而能够得到较佳的服务拓扑图。

具体的，采用统一分层布局算法，第一步、统计节点(应用服务)和维度信息(节点之间连线)；第二步、交叉最小化计算，使得节点之间的连线之间的交叉点最少；第三步、统计交叉点数量；第四步、进行坐标赋值；第五步、寻找对空间利用率最高的布局；第六步、得到布局信息。

还应该知道的是，为了区别出不同状态的应用服务，步骤102包括：

基于预设的多级阈值范围，由所述监测指标确定当前各个应用服务的目标阈值范围，并采用所述目标阈值范围对应的显示方式显示应用服务。

该实施例中，系统默认设置或用户自定义设置了多级阈值范围，在由监测指标确定服务拓扑图中当前各个应用服务落入的目标阈值范围后，既由该目标阈值范围对应的显示方式显示该应用服务。

这里，该多级阈值范围优选为对应应用服务中服务实例的健康比例，例如，设置了三级阈值范围分别是健康阈值范围、亚健康阈值范围和非健康阈值范围，对于落入健康阈值范围的应用服务，在服务拓扑图中会使用绿色显示其节点；对于落入亚健康阈值范围的应用服务，会使用橙色显示其节点；对于落入非健康阈值范围的应用服务，会使用红色显示其节点。如此，在图6的服务拓扑图中，可查看到节点Kafka为橙色，节点Apollo为红色，节点MySQL为绿色，因此可知Kafka当前状态为亚健康，Apollo当前状态为非健康，MySQL当前状态为健康。当然，对于服务实例的健康判断，会设置相应的健康判断阈值，在此不再赘述。

具体的，服务拓扑图中每个节点对应多个实例，可以用多个实例中健康的比例来判断该节点的健康状态。则可将阈值范围设置为一应用服务中满足监测指标阈值的实例数量，如设置的健康阈值范围(80％～100％)为该应用服务的目标阈值范围，即表示该应用服务中需要存在80％～100％的实例满足监测指标阈值。

并且，该实施例中，步骤102还包括：

基于所述监测指标，在所述服务拓扑图中呈现应用服务的健康状态。

这里，健康状态用于指示当前应用服务对应的监测指标的目标阈值范围。基于监测指标，通过在服务拓扑图中呈现应用服务的健康状态，更为直观地体现监测结果。

由上述内容可知，在该实施例中，服务拓扑图会通过节点显示应用服务的当前状态，而用户在特定场景下，除需要了解目标应用系统的应用服务状态外，还要对应用服务的各指标进行详细了解。因此，该实施例的方法还包括：

基于用户选择的目标节点，显示所述目标节点的节点信息，其中所述节点信息包括所述目标节点对应应用服务的类别、归属应用系统和机器项；

基于用户选择的目标机器项，显示与所述目标机器项对应的监测指标的监控数据。

这里，用户可在显示的服务拓扑图中选择目标节点，监测系统就会基于用户的选择对该目标节点的节点信息做具体的显示，包括目标节点对应应用服务的类别、归属应用系统和机器项等；之后，进一步由用户对机器项的选择，显示目标机器的预设指标的监控数据。其中，该机器项为目标节点对应应用服务的实例。例如图6所示的服务拓扑图，根据用户选择的目标节点Kafka，在当前界面的右侧区域显示了具体的类别、应用系统和机器项，并进一步显示了实例192.168.1.2:9092的CPU状态、内存状态和硬盘状态。这里显示的应用服务的节点信息以及预设指标的监控数据都是基于上述的应用服务指标监测得到的，在此不再赘述。

其中，对于具体监控数据的展示方式，多采用图表形式，以达到更为直观的效果。基于系统默认或用户自定义，可用直方图、饼图、环形图、折线图、面积图、雷达图、散点图、曲面图和列表中的至少一项的可视化展示。进一步需要说明的是，直方图可以为柱形图、条形图等，可用于显示数量、排序；饼图和环形图可用于显示占比；折线图和面积图可用于显示数量变化、动态变化情况。进一步地，以动态交互的方式展示。具体地，可以由系统默认或用户自定义，用直方图、饼图/环形图、折线图/面积图、雷达图、散点图、曲面图、列表等图表方式或上述方式的组合来呈现监测数据，并以动态交互的方式展示，例如当鼠标移动到或点击某具体位置(例如环形图中的具体区域)时显示对应的字段的详情。进一步地，可以实时监控，也可以设置监控刷新频率。

当然，在服务拓扑图中，不限于节点的监测，还可以由实时确定应用服务间的调用关系和数据流向实现连线的监测。例如，分析记录应用服务之间的调用频率，也支持设置应用服务之间的最低或者最高调用频率，当服务采集的调用频率低于或者高于调用预先分析的或者设置的门限频率，在连线上显示预警信息，如更改连线的颜色或文字预警等。

在本发明实施例中，所述方法还包括：

响应于用户基于所述目标节点和/或所述目标机器项的输入，执行对应处理；其中，所述处理包括以下至少之一：

调整监测指标；

显示所述目标机器项在指定时长内的状态；

显示指定监测指标的数据；

显示指定日志数据；

以及，分析异常原因和制定异常处理方案。

监测系统可实现用户基于目标节点和目标机器项的输入，可实现调整监测指标，即增加和/或删除某个节点的具体监测指标；可实现查看目标机器项在指定时长(如30分钟、1天)内的状态；可实现直接在服务拓扑图上进行运维操作，例如查看具体监测指标、具体日志数据、分析异常原因并给出异常处理方案等。

另外，该实施例中，用户还可在拓扑图列表界面对已生成的服务拓扑图进行目标的搜索，获取到目标服务拓扑图。具体的搜索可基于应用域、应用系统进行，而搜索到的目标服务拓扑图，可进行查看及编辑。

综上所述，本发明实施例的指标监测方法，首先会生成目标应用系统的服务拓扑图，然后结合该服务拓扑图和监测指标，针对服务拓扑图中节点对应的应用服务显示其当前状态，来实现应用服务的拓扑图状态显示，更便于用户对应用服务的监控及运维，大幅节省运维人员的工作量，提高了目标应用系统的运行稳定性。

参见图8，图8是本发明一实施例提供的指标监测系统的模块图。如图8所示，指标监测系统800包括：

生成模块801，用于生成目标应用系统的服务拓扑图；

第一显示模块802，用于根据所述服务拓扑图和监测指标，显示所述服务拓扑图中应用服务的当前状态。

可选地，所述生成模块801还用于：

根据用户在所述目标应用系统的服务拓扑图绘制界面的输入，生成所述服务拓扑图；或者

通过采集目标应用系统的组织架构生成服务拓扑图。

可选地，所述生成模块801还用于：

响应于用户对服务拓扑图的编辑输入，删除或添加对应的应用服务到服务拓扑图。

可选地，所述生成模块801包括：

处理子模块，用于根据所述目标应用系统采集的数据，得到生成所述服务拓扑图所需的目标信息；

确定子模块，用于根据所述目标信息，确定服务拓扑图的布局信息；

生成子模块，用于根据所述布局信息，生成服务拓扑图。

可选地，所述目标信息包括：应用服务信息，机器信息，以及各个应用服务之间的调用关系和数据流向；

所述处理子模块包括：

信息提取单元，用于提取采集到的数据中的应用服务信息和机器信息；

添加单元，用于在应用服务的服务请求中添加标识信息；

第一处理单元，用于根据所述服务请求的处理数据，获得所述标识信息的跟踪数据；

第二处理单元，用于根据所述跟踪数据，得到各个应用服务之间的调用关系和数据流向。

可选地，所述标识信息包括：服务请求标识和服务过程信息，所述服务过程信息用于表明当前应用服务对所述服务请求的处理过程；

所述第二处理单元包括：

获取子单元，用于获取所述跟踪数据中同属于一个服务请求标识的服务过程信息；

确定子单元，用于根据所述服务过程信息进行排序，确定各个应用服务之间的调用关系和数据流向。

可选地，所述确定子模块包括：

统计单元，用于根据所述目标信息，统计节点信息和节点间连线信息；

第三处理单元，用于基于交叉最小化规则计算节点坐标，并基于空间利用率最大化规则布局节点间的连线，得到所述布局信息。

可选地，所述系统还包括：

确定模块，用于根据用户在用户界面的输入，确定目标应用系统以及所述目标应用系统的应用服务。

其中，所述应用服务包括以下至少之一：计算引擎服务、存储服务、数据存储及搜索服务、数据库服务、消息队列服务、配置服务、监控服务、数据采集服务、数据查询服务和数据处理服务。

可选地，所述监测指标是对应所述应用服务设置的。

可选地，所述第一显示模块802还用于：

基于预设的多级阈值范围，由所述监测指标确定当前各个应用服务的目标阈值范围，并采用所述目标阈值范围对应的显示方式显示应用服务。

可选地，所述第一显示模块802还用于：

基于所述监测指标，在所述服务拓扑图中呈现应用服务的健康状态。

可选地，所述系统还包括：

第二显示模块，用于基于用户选择的目标节点，显示所述目标节点的节点信息，其中所述节点信息包括所述目标节点对应应用服务的类别、归属应用系统和机器项；

第三显示模块，用于基于用户选择的目标机器项，显示与所述目标机器项对应的监测指标的监控数据。

可选地，所述系统还包括：

处理模块，用于响应于用户基于所述目标节点和/或所述目标机器项的输入，执行对应处理；其中，所述处理包括以下至少之一：

调整监测指标；

显示所述目标机器项在指定时长内的状态；

显示指定监测指标的数据；

显示指定日志数据；

以及，分析异常原因和制定异常处理方案。

本发明实施例的指标监测系统是基于大数据技术的日志管理及分析系统，在功能上主要划分为生成模块和第一显示模块，首先会生成目标应用系统的服务拓扑图，然后结合该服务拓扑图和监测指标，针对服务拓扑图中节点对应的应用服务显示其当前状态，来实现应用服务的拓扑图状态显示，更便于用户对应用服务的监控，大幅节省运维人员的工作量，提高了目标应用系统的运行稳定性。

需要说明的是，该系统是应用了上述指标监测方法的系统，上述指标监测方法的实施例的实现方式适用于该系统，也能达到相同的技术效果。

本发明实施例还提供一种指标监测系统，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序；其中，所述处理器执行所述计算机程序时实现上述的指标监测方法中的步骤。

本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述的指标监测方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等。

进一步需要说明的是，此说明书中所描述的许多功能部件都被称为模块，以便更加特别地强调其实现方式的独立性。

本发明实施例中，模块可以用软件实现，以便由各种类型的处理器执行。举例来说，一个标识的可执行代码模块可以包括计算机指令的一个或多个物理或者逻辑块，举例来说，其可以被构建为对象、过程或函数。尽管如此，所标识模块的可执行代码无需物理地位于一起，而是可以包括存储在不同位置上的不同的指令，当这些指令逻辑上结合在一起时，其构成模块并且实现该模块的规定目的。

实际上，可执行代码模块可以是单条指令或者是许多条指令，并且甚至可以分布在多个不同的代码段上，分布在不同程序当中，以及跨越多个存储器设备分布。同样地，操作数据可以在模块内被识别，并且可以依照任何适当的形式实现并且被组织在任何适当类型的数据结构内。所述操作数据可以作为单个数据集被收集，或者可以分布在不同位置上(包括在不同存储设备上)，并且至少部分地可以仅作为电子信号存在于系统或网络上。

在模块可以利用软件实现时，考虑到现有硬件工艺的水平，所以可以以软件实现的模块，在不考虑成本的情况下，本领域技术人员都可以搭建对应的硬件电路来实现对应的功能，所述硬件电路包括常规的超大规模集成(VLSI)电路或者门阵列以及诸如逻辑芯片、晶体管之类的现有半导体或者是其它分立的元件。模块还可以用可编程硬件设备，诸如现场可编程门阵列、可编程阵列逻辑、可编程逻辑设备等实现。

上述范例性实施例是参考该些附图来描述的，许多不同的形式和实施例是可行而不偏离本发明精神及教示，因此，本发明不应被建构成为在此所提出范例性实施例的限制。更确切地说，这些范例性实施例被提供以使得本发明会是完善又完整，且会将本发明范围传达给那些熟知此项技术的人士。在该些图式中，组件尺寸及相对尺寸也许基于清晰起见而被夸大。在此所使用的术语只是基于描述特定范例性实施例目的，并无意成为限制用。如在此所使用地，除非该内文清楚地另有所指，否则该单数形式“一”、“一个”和“该”是意欲将该些多个形式也纳入。会进一步了解到该些术语“包含”及/或“包括”在使用于本说明书时，表示所述特征、整数、步骤、操作、构件及/或组件的存在，但不排除一或更多其它特征、整数、步骤、操作、构件、组件及/或其族群的存在或增加。除非另有所示，陈述时，一值范围包含该范围的上下限及其间的任何子范围。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种指标监测方法，其特征在于，所述方法包括：

生成目标应用系统的服务拓扑图；

根据所述服务拓扑图和监测指标，显示所述服务拓扑图中应用服务的当前状态。

2.如权利要求1所述的方法，其特征在于，所述生成目标应用系统的服务拓扑图的步骤，包括：

根据用户在所述目标应用系统的服务拓扑图绘制界面的输入，生成所述服务拓扑图；或者

通过采集目标应用系统的组织架构生成服务拓扑图。

3.如权利要求2所述的方法，其特征在于，所述通过采集目标应用系统的组织架构生成服务拓扑图的步骤，包括：

根据所述目标应用系统采集的数据，得到生成所述服务拓扑图所需的目标信息；

根据所述目标信息，确定服务拓扑图的布局信息；

根据所述布局信息，生成服务拓扑图。

4.如权利要求1所述的方法，其特征在于，所述根据所述服务拓扑图和监测指标，显示所述服务拓扑图中应用服务的当前状态的步骤，还包括：

基于所述监测指标，在所述服务拓扑图中呈现应用服务的健康状态。

5.如权利要求1所述的方法，其特征在于，在所述显示所述服务拓扑图中应用服务的当前状态的步骤之后，所述方法还包括：

基于用户选择的目标节点，显示所述目标节点的节点信息，其中所述节点信息包括所述目标节点对应应用服务的类别、归属应用系统和机器项；

基于用户选择的目标机器项，显示与所述目标机器项对应的监测指标的监控数据。

6.一种指标监测系统，其特征在于，所述指标监测系统包括：

生成模块，用于生成目标应用系统的服务拓扑图；

第一显示模块，用于根据所述服务拓扑图和监测指标，显示所述服务拓扑图中应用服务的当前状态。

7.如权利要求6所述的系统，其特征在于，所述生成模块还用于：

根据用户在所述目标应用系统的服务拓扑图绘制界面的输入，生成所述服务拓扑图；或者

通过采集目标应用系统的组织架构生成服务拓扑图。

8.如权利要求7所述的系统，其特征在于，所述生成模块包括：

处理子模块，用于根据所述目标应用系统采集的数据，得到生成所述服务拓扑图所需的目标信息；

确定子模块，用于根据所述目标信息，确定服务拓扑图的布局信息；

生成子模块，用于根据所述布局信息，生成服务拓扑图。

9.如权利要求6所述的系统，其特征在于，所述第一显示模块还用于：

基于所述监测指标，在所述服务拓扑图中呈现应用服务的健康状态。

10.如权利要求6所述的系统，其特征在于，所述系统还包括：

第二显示模块，用于基于用户选择的目标节点，显示所述目标节点的节点信息，其中所述节点信息包括所述目标节点对应应用服务的类别、归属应用系统和机器项；

第三显示模块，用于基于用户选择的目标机器项，显示与所述目标机器项对应的监测指标的监控数据。