监控框架设计方法和监控服务器、代理单元、中控服务器

摘要

本发明实施例公开了监控框架设计方法和监控服务器、代理单元、中控服务器，用于实现立体化全方位的监控体系。本发明实施例的一种监控框架设计方法包括：监控服务器获取各个虚拟机中代理单元分别上报的监控数据，从中控服务器获取所述中控服务器对所述各个虚拟机控制时存在的监控数据；所述监控服务器将获取到的监控数据存储到数据库中；所述监控服务器从所述数据库中读取监控数据进行异常分析，对存在异常的监控数据进行告警，并将所述存在异常的监控数据存储到所述数据库中。

说明书

技术领域

本发明涉及计算机技术领域，尤其涉及一种监控框架设计方法和监控服务器、代理单元、中控服务器。

背景技术

云计算基础设施平台是一个复杂的服务平台，具有多样化、异构性和动态变化的特点。云计算系统的正常运行离不开云监控系统的支持，云监控系统能够实时反映出云平台的运行状况，能够及时发现和处理云计算平台己发生和潜在的问题，这对于管理和调度云计算系统资源起到了关键性的作用。因此，如何设计监控框架对于云计算系统的正常运维起着决定性的作用。现有技术中对怎样设计监控框架才能满足云计算系统的需求没有确切规定。

发明内容

本发明实施例提供了一种监控框架设计方法和监控服务器、代理单元、中控服务器，用于实现立体化全方位的监控体系。

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

第一方面，本发明实施例提供一种监控框架设计方法，包括：

监控服务器获取各个虚拟机中代理单元分别上报的监控数据，从中控服务器获取所述中控服务器对所述各个虚拟机控制时存在的监控数据；

所述监控服务器将获取到的监控数据存储到数据库中；

所述监控服务器从所述数据库中读取监控数据进行异常分析，对存在异常的监控数据进行告警，并将所述存在异常的监控数据存储到所述数据库中。

第二方面，本发明实施例还提供一种监控框架设计方法，包括：

代理单元监控虚拟机，根据所述虚拟机的运行数据产生监控数据，所述代理单元部署在所述虚拟机中；

所述代理单元向监控服务器上报所述监控数据。

第三方面，本发明实施例还提供一种监控框架设计方法，包括：

中控服务器产生在对各个虚拟机进行控制时的监控数据；

所述中控服务器根据监控服务器的请求向所述监控服务器发送所述监控数据。

第四方面，本发明实施例还提供一种监控服务器，包括：

收集单元，用于获取各个虚拟机中代理单元分别上报的监控数据，从中控服务器获取所述中控服务器对所述各个虚拟机控制时存在的监控数据；

存储单元，将获取到的监控数据存储到数据库中；

告警单元，用于从所述数据库中读取监控数据进行异常分析，对存在异常的监控数据进行告警；

所述存储单元，还用于将所述存在异常的监控数据存储到所述数据库中。

第五方面，本发明实施例还提供一种代理单元，所述代理单元部署在所述虚拟机中，包括：监控子单元和发送子单元，其中，

所述监控子单元，用于监控虚拟机，根据所述虚拟机的运行数据产生监控数据，

所述发送子单元，用于向监控服务器上报所述监控数据。

第六方面，本发明实施例还提供一种中控服务器，包括：数据生成单元和发送单元，其中，

所述数据生成单元，用于产生在对各个虚拟机进行控制时的监控数据；

所述发送单元，用于根据监控服务器的请求向所述监控服务器发送所述监控数据。

从以上技术方案可以看出，本发明实施例具有以下优点：

在本发明实施例中，监控服务器获取各个虚拟机中代理单元分别上报的监控数据，从中控服务器获取中控服务器对各个虚拟机控制时存在的监控数据，监控服务器将获取到的监控数据存储到数据库中，监控服务器从数据库中读取监控数据进行异常分析，对存在异常的监控数据进行告警，并将存在异常的监控数据存储到数据库中。由于监控服务器获取到的监控数据的来源包括各个虚拟机以及对虚拟机进行控制的中控服务器，监控服务器的监控面 更广，覆盖到了虚拟机自身以及对各个虚拟机进行控制的中控服务器，基于从虚拟机和中控服务器收集到的监控数据进行的异常分析能够准确的确定产生异常的监控数据，并对异常的监控数据进行告警，实现了立体化全方位的监控体系。

附图说明

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

图1为本发明实施例提供的一种监控框架设计方法的流程方框示意图；

图2为本发明实施例提供的另一种监控框架设计方法的流程方框示意图；

图3为本发明实施例提供的另一种监控框架设计方法的流程方框示意图；

图4-a为本发明实施例提供的一种立体化监控框架的设计结构示意图；

图4-b为本发明实施例提供的监控框架中对监控数据的处理流程示意图；

图5-a为本发明实施例提供的一种监控服务器的组成结构示意图；

图5-b为本发明实施例提供的另一种监控服务器的组成结构示意图；

图5-c为本发明实施例提供的一种收集单元的组成结构示意图；

图6为本发明实施例提供的一种代理单元的组成结构示意图；

图7为本发明实施例提供的一种中控服务器的组成结构示意图；

图8为本发明实施例提供的监控框架设计方法应用于监控服务器的组成结构示意图；

图9为本发明实施例提供的监控框架设计方法应用于虚拟机的组成结构示意图；

图10为本发明实施例提供的监控框架设计方法应用于中控服务器的组成结构示意图。

具体实施方式

本发明实施例提供了一种监控框架设计方法和监控服务器、代理单元、中控服务器，用于实现立体化全方位的监控体系。

为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，下面所描述的实施例仅仅是本发明一部分实施例，而非全部实施例。基于本发明中的实施例，本领域的技术人员所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。

以下分别进行详细说明。

本发明监控框架设计方法中，监控服务器用于实现监控框架，监控服务器与各个虚拟机以及对各个虚拟机进行控制的中控服务器都建立有通信连接，监控服务器通过对虚拟机以及中控服务器的监控，可以对发生的故障有准确及时的告警，从而方便运维人员快速定位解决问题，保证用户服务质量。本发明实施例提供的监控框架设计方法可实现立体化全方位的监控体系。接下分别对监控服务器、虚拟机、中控服务器执行监控框架设计中各个设备实现的方法进行举例说明。

本发明监控框架设计方法的一个实施例，具体可以应用于监控服务器中，请参阅图1所示，本发明一个实施例提供的控框架设计方法，可以包括如下步骤：

101、监控服务器获取各个虚拟机中代理单元分别上报的监控数据，从中控服务器获取中控服务器对各个虚拟机控制时存在的监控数据。

在本发明实施例中，为了使监控服务器能够准确及时的确定故障并进行告警，在各个虚拟机中分别部署代理单元，由代理单元收集虚拟机的运行数据并生成对各个虚拟机进行监控的监控数据，中控服务器在对虚拟机进行控制时也产生监控数据，本发明的监控框架中需要配置虚拟机中代理单元向监控服务器上报监控数据，也需要配置监控服务器从中控服务器请求监控数据， 所以监控服务器需要获取各个虚拟机中代理单元分别上报的监控数据，从中控服务器获取中控服务器对各个虚拟机控制时存在的监控数据，由于监控服务器获取到的监控数据的来源包括各个虚拟机以及对虚拟机进行控制的中控服务器，监控服务器的监控面更广，覆盖到了虚拟机自身以及对各个虚拟机进行控制的中控服务器。

进一步的，为了实现更加精细的监控服务，在本发明的一些实施例中，步骤101中监控服务器获取各个虚拟机中代理单元分别上报的监控数据，具体可以包括如下步骤：

A1、监控服务器获取各个虚拟机中代理单元按照预置的各个监控项以及收集周期实时上报的监控数据。

也就是说，为了使得监控服务器能够更加精细提供监控服务，还需要对部署在虚拟机中的代理单元进行预先设置配置文件，代理单元按照配置文件的要求对虚拟机进行监控，例如在配置文件中设置需要监控的监控项以及设置代理单元的收集周期，那么代理单元就需要根据配置文件设置的监控项对虚拟机的各项运行数据分别进行实时监控，按照配置文件设置的收集周期向监控服务器上报多组的监控数据。具体的，对代理单元设置的配置文件中预置的监控项可包括：虚拟机的系统层和进程层，即代理单元收集该代理单元所在的虚拟机中的系统层数据和进程层数据，代理单元向监控服务器上报虚拟机的系统层数据和进程层数据。

需要说明的是，虚拟机的系统层指的是虚拟机的底层硬件层面，系统层数据指的是对虚拟机的底层基础设施类进行监控得到的监控数据，包括但不局限于如下举例的情况都属于系统层数据：网络带宽占用情况、包量负载，物理内容量、虚拟机内存容量，网卡速率，解析dmesg信息，对各种系统堆栈、输入输出端口(Input/Output，I/O)。虚拟机的进程层指的是虚拟机上的关键进程层面，进程层数据指的是对虚拟机上的关键进程的运行状态进行监控得到的监控数据，包括但不局限于如下举例的情况都属于进程层数据：中央处理器(Central Processing Unit，CPU)使用率情况，内存占用情况，磁盘使用情况。

进一步的，步骤101中从中控服务器获取中控服务器对各个虚拟机控制 时存在的监控数据，具体可以包括如下步骤：

A2、监控服务器从中控服务器获取中控服务器按照预置的各个监控项以及收集周期实时发送的监控数据。

也就是说，为了使得监控服务器能够更加精细提供监控服务，还需要对监控服务器进行预先设置配置文件，监控服务器按照配置文件的要求向中控服务器请求监控数据，例如在配置文件中设置需要监控的监控项以及设置收集周期，那么监控服务器就需要根据配置文件设置的监控项以及收集周期定时的向中控服务器请求监控数据，具体的，对监控服务器设置的配置文件中预置的监控项可包括：中控服务器中的模块层、平台层和用户层，即监控服务器需要从中控服务器拉取模块层数据、平台层数据和用户层数据，中控服务器按照监控服务器的请求向监控服务器反馈模块层数据、平台层数据和用户层数据。

需要说明的是，中控服务器中可部署虚拟化平台，虚拟化平台可实现资源分配、回收、流转，中控服务器中部署该虚拟化平台可实现对资源的集中管理，另外中控服务器还通过虚拟化平台部署多个模块，模块是实现虚拟化平台的各个组成部分，通过各模块交互完成资源的分配等等，中控服务器中的平台层指的是虚拟化平台层面，平台层数据指的是中控服务器对虚拟化平台进行监控得到的监控数据，包括但不局限于如下举例的情况都属于平台层数据：虚拟化平台内部的数据流转和应用程序编程接口(ApplicationProgramming Interface，API)调用。中控服务器中的模块层指的是虚拟化平台中包括的各个模块层面，模块层数据指的是中控服务器对虚拟化平台中各个模块进行监控得到的监控数据，包括但不局限于如下举例的情况都属于模块层数据：虚拟化平台内部相关模块的状态、耗时、存活等情况。中控服务器中的用户层指的是中控服务器对用户使用虚拟机时的用户层面，用户层数据指的是中控服务器对用户使用虚拟机进行监控得到的监控数据，包括但不局限于如下举例的情况都属于用户层数据：用户使用虚拟机的CPU使用率，用户使用虚拟机的I/O，用户使用虚拟机的网络使用情况。

在本发明的一些实施例中，针对代理单元需要上报的监控项不同，步骤101监控服务器获取各个虚拟机中代理单元分别上报的监控数据，具体包括如 下步骤：

B1、监控服务器获取各个虚拟机中代理单元分别上报的系统层数据和进程层数据。

其中，代理单元中设置的配置文件要求代理单元上报的监控项包括：系统层和进程层，例如按照不同监控维度设置为每个监控项设置全局唯一的监控(Identity，ID)，则系统层监控项和进程层监控项分别使用不同的监控ID，代理单元使用系统层的监控ID标识系统层数据，使用进程层的监控ID标识进程层数据，监控服务器接收代理单元上报的系统层数据和进程层数据，根据系统层的监控ID和进程层的监控ID识别出系统层数据和进程层数据。

进一步的，在执行步骤B1的实现场景下，步骤B1监控服务器获取各个虚拟机中代理单元分别上报的系统层数据和进程层数据，具体可以包括如下步骤：

监控服务器中设置系统收集单元和进程收集单元，系统收集单元，用于接收各个虚拟机中代理单元分别上报的系统层数据；进程收集单元，用于接收各个虚拟机中代理单元分别上报的进程层数据。

也就是说，在具体实现层面，监控服务器中需要针对各层的监控项设计各自的收集单元，针对系统层设置系统收集单元，针对进程层设置进程收集单元，以保证灵活性，系统收集单元和进程收集单元分别将接收各个代理单元上报的监控数据。

在本发明的一些实施例中，针对代理单元需要上报的监控项不同，步骤101从中控服务器获取中控服务器对各个虚拟机控制时存在的监控数据，具体包括如下步骤：

B2、监控服务器从中控服务器获取中控服务器通过虚拟化平台控制各个虚拟机时存在的模块层数据、平台层数据和用户层数据，虚拟化平台上部署有多个模块，用户层数据包括：用户使用虚拟机时存在的虚拟机运行数据。

其中，监控服务器中设置的配置文件要求监控服务器从中控服务器获取的监控项包括：模块层、平台层和用户层，例如按照不同监控维度设置为每个监控项设置全局唯一的监控ID，则模块层监控项、平台层监控项和用户层监控项分别使用不同的监控ID，监控服务器使用模块层的监控ID标识模块层 数据，使用平台层的监控ID标识平台层数据，使用用户层的监控ID标识用户层数据，监控服务器从中控服务器获取中控服务器通过虚拟化平台控制各个虚拟机时存在的模块层数据、平台层数据和用户层数据，根据模块层的监控ID、平台层的监控ID和用户层的监控ID识别出模块层数据、平台层数据和用户层数据。

进一步的，在执行步骤B2的实现场景下，步骤B2监控服务器从中控服务器获取中控服务器通过虚拟化平台控制各个虚拟机时存在的模块层数据、平台层数据和用户层数据，具体可以包括如下步骤：

监控服务器中设置模块收集单元、平台收集单元和用户收集单元，模块收集单元，用于从中控服务器拉取中控服务器通过虚拟化平台控制各个虚拟机时产生的模块层数据；平台收集单元，用于从中控服务器拉取虚拟化平台的平台层数据；用户收集单元，用于从中控服务器拉取用户使用虚拟机时产生的用户层数据。

也就是说，在具体实现层面，监控服务器中需要针对各层的监控项设计各自的收集单元，针对模块层设置模块收集单元，针对平台层设置平台收集单元，针对用户层设置用户收集单元，以保证灵活性，模块收集单元、平台收集单元和用户收集单元分别将接收中控服务器返回的监控数据。

102、监控服务器将获取到的监控数据存储到数据库中。

在本发明实施例中，监控服务器从代理单元获取到监控数据以及从中控服务器获取到监控数据之后，监控服务器获取到的监控数据就包括：来自于各个虚拟机中代理单元发送的监控数据和中控服务器发送的监控数据，监控服务器中部署有数据库(Data Base，DB)，监控服务器将获取到的监控数据都存储到数据库中，数据库中存储有监控服务器获取到的监控数据，这些监控数据可以在需要时由监控服务器进行调取。

在发明的一些实施例中，对于执行前述步骤B1的应用场景，步骤102监控服务器将获取到的监控数据存储到数据库中，具体可以包括如下步骤：

监控服务器中设置系统数据子库和进程数据子库，监控服务器将系统层数据存储到系统数据子库中，将进程层数据存储到进程数据子库中。

同样的，对于执行前述步骤B2的应用场景，步骤102监控服务器将获取 到的监控数据存储到数据库中，包括：

监控服务器中设置模块数据子库、平台数据子库和用户数据子库，监控服务器将模块层数据存储到模块数据子库中，将平台层数据存储到平台数据子库中，将用户层数据存储到用户数据子库中。

也就是说，数据库中可以根据监控项设置的精细程度来分别存储监控数据，在数据库中按照监控项也进行划分出五个存储空间，针对存储监控数据的监控ID表示为：系统数据子库、进程数据子库、模块数据子库、平台数据子库和用户数据子库，每个子库存储对应该子库的监控数据，方便监控服务器对监控数据的分类存储，若监控服务器需要调用各个监控项的监控时，可实现高效。快捷。

103、监控服务器从数据库中读取监控数据进行异常分析，对存在异常的监控数据进行告警，并将存在异常的监控数据存储到数据库中。

在本发明实施例中，监控服务器从各个虚拟机的代理单元和中控服务器收集到的监控数据都存放在数据库中，监控服务器可以实时的从该数据库中读取出监控数据，然后对读取到的监控数据进行异常分析，从而确定出存在异常的监控数据进行告警，需要说明的是，监控服务器确定监控数据是否产生异常需要结合具体的应用场景以及运维人员对监控服务器可提供的具体监控服务有关，在不同的场景下对监控数据的异常分析可采用具体的数据分析方式，另外监控服务器对存在异常的监控数据进行告警也可以有多种实现方式，例如优先级高的信息指示，或者采用动画、音效以及特定程序均可以作为告警的方式，可以通过预先配置告警ID指示具体的告警方式，此处不做限定。另外监控服务器在分析出存在异常的监控数据之后，还需要将该存在异常的监控数据进行存储，将其存储到监控服务器中部署的数据库中，可以理解的是，数据库在存储前述步骤102中监控服务器获取到的监控数据以及存储存在异常的监控数据时，只需要采用不同的存储索引表即可，两类监控数据是分开存储的，以便监控服务器的后续调用。

在本发明的一些实施例中，步骤103中将存在异常的监控数据存储到数据库中之后，本发明提供的监控框架设计方法还可以包括如下步骤：

C1、监控服务器从数据库中提取出存在异常的监控数据，并向外展示以 便进行故障分析。

也就是说，监控服务器在确定出存在异常的监控数据并告警之后，为方便运维人员进行故障的快速定位分析，监控服务器还需要从数据库中提取存在异常的监控数据，并向外展示以便进行故障分析，例如运监控服务器可以通过运营支撑系统(Operation Support System，OSS)向运维人员输出异常的监控数据，由运维人员快速定位解决问题，保证用户服务质量。具体的，可以在监控服务器中部署展示单元，由展示单元与外界输出存在异常的监控数据。具体的，展示单元，可以包括：系统展示单元、进程展示单元、模块展示单元、平台展示单元和用户展示单元，相应的展示单元用于实现对相应监控项的展示。

在本发明的一些实施例中，对于执行前述步骤A1和A2的应用场景，步骤103中监控服务器从数据库中读取监控数据进行异常分析，包括：

监控服务器根据获取到的多组监控数据进行异常分析，确定出存在异常的监控项。

进一步的，在前述的实现场景下，步骤103对存在异常的监控数据进行告警，具体可以包括如下步骤：

监控服务器对确定存在异常的同一个监控项的多个异常监控数据进行聚合，按照聚合结果进行集中告警。

也就是说，若监控服务器从代理单元或者中控服务器收到多组的监控数据，对同一个监控项内的多组监控数据的横向分析，也可以对实现对监控框架的自我监控，进一步的，监控服务器中可设置告警单元，用于存在异常的监控数据进行告警，举例说明：以虚拟机上网卡丢包为例，虚拟机上的代理单元是每5分钟采集一次上报一次，监控服务器就会每5分钟收到代理单元上报的监控数据，那数据库中会每5分钟存放一个丢包信息，如果告警单元不做聚合的话，会每5分钟发出一个告警，这样会有大量的信息冗余，若告警单元对告警进行聚合计算，通过把这类信息聚合在一起一次性发出告警，避免不必要的干扰。，告警单元为了抑制告警风暴，还可以对同一个监控项的多个告警进行聚合，在聚合结果中携带多个异常监控数据，可实现集中告警。具体的，告警单元，可以包括：系统告警单元、进程告警单元、模块告警单 元、平台告警单元和用户告警单元，相应的告警单元用于实现对相应监控项的告警。

通过以上实施例对本发明实施例的描述可知，监控服务器获取各个虚拟机中代理单元分别上报的监控数据，从中控服务器获取中控服务器对各个虚拟机控制时存在的监控数据，监控服务器将获取到的监控数据存储到数据库中，监控服务器从数据库中读取监控数据进行异常分析，对存在异常的监控数据进行告警，并将存在异常的监控数据存储到数据库中。由于监控服务器获取到的监控数据的来源包括各个虚拟机以及对虚拟机进行控制的中控服务器，监控服务器的监控面更广，覆盖到了虚拟机自身以及对各个虚拟机进行控制的中控服务器，基于从虚拟机和中控服务器收集到的监控数据进行的异常分析能够准确的确定产生异常的监控数据，并对异常的监控数据进行告警，实现了立体化全方位的监控体系。

以上从监控服务器侧对本发明监控框架设计方法进行了举例说明，接下来介绍本发明实施例提供的另一种监控框架设计方法，具体可以应用于各个虚拟机中部署的代理单元中，请参阅图2所示，本发明一个实施例提供的控框架设计方法，可以包括如下步骤：

201、代理单元监控虚拟机，根据虚拟机的运行数据产生监控数据，代理单元部署在虚拟机中。

202、代理单元向监控服务器上报监控数据。

在发明实施例中，为了使监控服务器能够准确及时的确定故障并进行告警，在各个虚拟机中分别部署一个代理单元，由代理单元收集本虚拟机的运行数据并生成对各个虚拟机进行监控的监控数据，每个虚拟机上都部署代理单元，由代理单元主动向监控服务器上报，主动上报的方式避免单点收集监控信息，也就是说，对所有虚拟机信息的获取是通过在每个虚拟机上部署代理单元实现的，而不是通过监控服务器上一个程序来获取所有虚拟机的监控数据。

在本发明的一些实施例中，步骤201代理单元监控虚拟机，根据虚拟机的运行数据产生监控数据，具体可以包括如下步骤：

代理单元根据配置文件设置的监控项对虚拟机的各项运行数据分别进行 实时监控，按照配置文件设置的收集周期产生多组的监控数据。

也就是说，为了使得监控服务器能够更加精细提供监控服务，还需要对部署在虚拟机中的代理单元进行预先设置配置文件，代理单元按照配置文件的要求对虚拟机进行监控，例如在配置文件中设置需要监控的监控项以及设置代理单元的收集周期，那么代理单元就需要根据配置文件设置的监控项对虚拟机的各项运行数据分别进行实时监控，按照配置文件设置的收集周期向监控服务器上报多组的监控数据。具体的，对代理单元设置的配置文件中预置的监控项可包括：虚拟机的系统层和进程层，即代理单元收集该代理单元所在的虚拟机中的系统层数据和进程层数据，代理单元向监控服务器上报虚拟机的系统层数据和进程层数据。

需要说明的是，虚拟机的系统层指的是虚拟机的底层硬件层面，系统层数据指的是对虚拟机的底层基础设施类进行监控得到的监控数据，包括但不局限于如下举例的情况都属于系统层数据：网络带宽占用情况、包量负载，物理内容量、虚拟机内存容量，网卡速率，解析dmesg信息，对各种系统堆栈、I/O。虚拟机的进程层指的是虚拟机上的关键进程层面，进程层数据指的是对虚拟机上的关键进程的运行状态进行监控得到的监控数据，包括但不局限于如下举例的情况都属于进程层数据：CPU使用率情况，内存占用情况，磁盘使用情况。

进一步的，若监控数据包括：系统层数据和进程层数据，步骤202代理单元向监控服务器上报监控数据，具体可以包括如下步骤：

代理单元向监控服务器中设置的系统收集单元发送系统层数据，向监控服务器中设置的进程收集单元发送进程层数据。

也就是说，在具体实现层面，监控服务器中需要针对各层的监控项设计各自的收集单元，针对系统层设置系统收集单元，针对进程层设置进程收集单元，以保证灵活性，系统收集单元和进程收集单元分别将接收各个代理单元上报的监控数据。

通过以上实施例对本发明实施例的描述可知，各个虚拟机中代理单元分别向监控服务器上报的监控数据，监控服务器还从中控服务器获取中控服务器对各个虚拟机控制时存在的监控数据，监控服务器将获取到的监控数据存 储到数据库中，监控服务器从数据库中读取监控数据进行异常分析，对存在异常的监控数据进行告警，并将存在异常的监控数据存储到数据库中。由于监控服务器获取到的监控数据的来源包括各个虚拟机以及对虚拟机进行控制的中控服务器，监控服务器的监控面更广，覆盖到了虚拟机自身以及对各个虚拟机进行控制的中控服务器，基于从虚拟机和中控服务器收集到的监控数据进行的异常分析能够准确的确定产生异常的监控数据，并对异常的监控数据进行告警，实现了立体化全方位的监控体系。

以上从监控服务器侧对本发明监控框架设计方法进行了举例说明，接下来介绍本发明实施例提供的另一种监控框架设计方法，具体可以应用于中控服务器中，请参阅图3所示，本发明一个实施例提供的控框架设计方法，可以包括如下步骤：

301、中控服务器产生在对各个虚拟机进行控制时的监控数据。

302、中控服务器根据监控服务器的请求向监控服务器发送监控数据。

在发明实施例中，中控服务器也可以称之为中央控制服务器，中央控制服务器用于对各个虚拟机进行控制，为了使监控服务器能够准确及时的确定故障并进行告警，中控服务器在对虚拟机进行控制时产生监控数据，本发明的监控框架中需要配置监控服务器从中控服务器请求监控数据，所以监控服务器需要获取各个虚拟机中代理单元分别上报的监控数据，从中控服务器获取中控服务器对各个虚拟机控制时存在的监控数据。中控服务器向监控服务器提供该中控服务器对虚拟机控制时存在的监控数据，使得中控服务器可以配合监控服务器完善监控框架的设计，中控服务器提供的监控数据可以满足监控服务器对全方位立体化监控的需要，相比于现有技术中监控服务器单一的监控数据来源更具有针对性。

在本发明的一些实施例中，步骤301中控服务器产生在对各个虚拟机进行控制时的监控数据，具体可以包括如下步骤：

中控服务器根据配置文件设置的监控项以及收集周期分别产生多组的监控数据。

也就是说，为了使得监控服务器能够更加精细提供监控服务，还需要对监控服务器进行预先设置配置文件，监控服务器按照配置文件的要求向中控 服务器请求监控数据，例如在配置文件中设置需要监控的监控项以及设置收集周期，那么监控服务器就需要根据配置文件设置的监控项以及收集周期定时的向中控服务器请求监控数据，具体的，对监控服务器设置的配置文件中预置的监控项可包括：中控服务器中的模块层、平台层和用户层，即监控服务器需要从中控服务器拉取模块层数据、平台层数据和用户层数据，中控服务器按照监控服务器的请求向监控服务器反馈模块层数据、平台层数据和用户层数据。

需要说明的是，中控服务器中可部署虚拟化平台，虚拟化平台可实现资源分配、回收、流转，中控服务器中部署该虚拟化平台可实现对资源的集中管理，另外中控服务器还通过虚拟化平台部署多个模块，模块是实现虚拟化平台的各个组成部分，通过各模块交互完成资源的分配等等，中控服务器中的平台层指的是虚拟化平台层面，平台层数据指的是中控服务器对虚拟化平台进行监控得到的监控数据，包括但不局限于如下举例的情况都属于平台层数据：虚拟化平台内部的数据流转和API。中控服务器中的模块层指的是虚拟化平台中包括的各个模块层面，模块层数据指的是中控服务器对虚拟化平台中各个模块进行监控得到的监控数据，包括但不局限于如下举例的情况都属于模块层数据：虚拟化平台内部相关模块的状态、耗时、存活等情况。中控服务器中的用户层指的是中控服务器对用户使用虚拟机时的用户层面，用户层数据指的是中控服务器对用户使用虚拟机进行监控得到的监控数据，包括但不局限于如下举例的情况都属于用户层数据：用户使用虚拟机的CPU使用率，用户使用虚拟机的I/O，用户使用虚拟机的网络使用情况。

进一步的，若监控数据包括：模块层数据、平台层数据和用户层数据，步骤302中控服务器根据监控服务器的请求向监控服务器发送监控数据，具体可包括如下步骤：

中控服务器向监控服务器中设置的模块收集单元发送模块层数据，向监控服务器中设置的平台收集单元发送平台层数据，向监控服务器中设置的用户收集单元发送用户层数据。

也就是说，在具体实现层面，监控服务器中需要针对各层的监控项设计各自的收集单元，针对模块层设置模块收集单元，针对平台层设置平台收集 单元，针对用户层设置用户收集单元，以保证灵活性，模块收集单元、平台收集单元和用户收集单元分别将接收中控服务器返回的监控数据。

通过以上实施例对本发明实施例的描述可知，中控服务器向监控服务器发送中控服务器对各个虚拟机控制时存在的监控数据，监控服务器还获取各个虚拟机中代理单元分别上报的监控数据，监控服务器将获取到的监控数据存储到数据库中，监控服务器从数据库中读取监控数据进行异常分析，对存在异常的监控数据进行告警，并将存在异常的监控数据存储到数据库中。由于监控服务器获取到的监控数据的来源包括各个虚拟机以及对虚拟机进行控制的中控服务器，监控服务器的监控面更广，覆盖到了虚拟机自身以及对各个虚拟机进行控制的中控服务器，基于从虚拟机和中控服务器收集到的监控数据进行的异常分析能够准确的确定产生异常的监控数据，并对异常的监控数据进行告警，实现了立体化全方位的监控体系。

为便于更好的理解和实施本发明实施例的上述方案，下面举例相应的应用场景来进行具体说明。

本发明提供的监控框架设计方法可实现立体化全方位的监控体系，例如在基础设施即服务(Infrasturcture-as-a-Service，IaaS)的云计算体系，对云计算系统的稳定性有严格的要求，结合本发明可以实现对云计算系统的严密监控，并对发生的故障有准确及时的告警，从而方便运维人员快速定位解决问题，保证用户服务质量。

首先对本发明的立体化监控方案组成结构进行说明，请参阅如图4-a所示，为本发明实施例提供的一种立体化监控框架的设计结构示意图，立体化监控方案将监控项细分为五个层面实现对云计算系统的严密监控，分别是用户层，平台层，模块层，进程层和系统层。其中，这五层监控项可实现对虚拟化的全方位监控。

接下来从监控框架中从监控服务器、中控服务器、虚拟机中的代理单元对监控数据的处理流程进行说明，请参阅图4-b所示，为本发明实施例提供的监控框架中对监控数据的处理流程示意图。监控服务器中划分为四个主要层次：收集单元，数据库，告警单元和展示单元。

1)、虚拟机中的代理单元主要负责收集本地系统层和进程层的关键信息， 并上报给对应的中心节点，例如系统层数据上报给系统收集单元，进程层数据上报给进程收集单元。

例如，在所有虚拟机上部署监控程序(即代理单元)，代理单元注册各监控项的监控ID，并根据配置文件确定各监控ID的收集上报频率。

2)、系统收集单元和进程收集单元负责完成接收代理单元的上报的系统层数据和进程层数据，模块收集单元、平台收集单元和用户收集单元从中控服务器拉取模块层数据、平台层数据和用户层数据。

具体的，对五层监控维度的不同监控项设置全局唯一的监控ID，加速对系统的故障定位。代理单元和收集单元可利用APScheduler实现定时任务，APScheduler是基于Quartz的一个python框架，可以提供基于日期、固定时间间隔以及crontab类型的任务，并且可以持久化任务，从而实现采集监控数据的灵活性。

对于数据库，可采用两种数据库：内存数据库redis和mysql，收集单元实时地将代理单元上报的监控数据刷新到redis中，redis是一个开源的基于key-value的NoSQL数据库，具有高性能和高可用性，可以应对高并发访问。收集单元定期的将redis数据导入到mysql中，mysql存放所有的元数据和监控数据，并保证监控数据是连续的，同时利用HAProxy横向集群扩展，突破单机的mysql读写瓶颈，保证系统的稳定性。

3)、告警单元从各个数据子库中提取出监控数据，确定出存在异常的监控数据，并对监控数据进行聚合计算，根据告警项配置实现灵活、多种方式的告警。例如，告警单元在告警内容中增加dmesg的解析结果，方便快速定位和分析故障。其中，存在异常的监控数据可以是用户层数据、进程层数据和系统层数据，这些监控数据的异常可能会造成虚拟机不可用，若平台层数据和模块层数据存在异常会使用户无法对虚拟机进行操作，如关机，重启等。例如，运维工具使用tornado web服务器框架实现，tornado具有非阻塞、速度快的特点，可以方便的增加删除功能，从而实现OSS的前后端分离，保证系统的可扩展性和灵活性。

4)、展示单元从各监控项的数据子库中实时获取监控数据，提供对云计算系统实时的状态监控，并提供多种运维工具，方便运维人员快速的操作， 修复故障，分析原因。其中，运维工具可以是云计算系统内部对故障处理流程的工具，比如说，创建一个故障单，记录故障并跟踪故障的解决情况。

通过以上的举例说明可知，本发明监控框架设计方法的监控面广泛，从系统的最底层硬件、关键进程，平台模块等到最高层应用全面覆盖，监控数据连续集中，使对监控数据的分析非常方便，并且具有去单点，可扩展，自我监控，告警及时准确的特点。设置全局唯一的监控ID，通过监控ID可以方便地故障类型，告警内容中增加解析dmesg信息，加速故障定位与分析。代理单元部署在所有虚拟机上，主动上报的方式避免单点收集监控信息。各监控层连接各自的收集单元，使收集单元的功能简化方便去除、添加和升级，扩展性好。告警单元实时的对连续的监控数据进行分析，依据监控项的监控ID聚合告警信息，抑制告警风暴。另外，监控框架设计上要求监控数据是连续的，无论监控信息是否异常都需要上报监控结果，如果缺少相应的监控数据，可以确定代理单元所在的虚拟机存在异常，从而实现自我监控。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

为便于更好的实施本发明实施例的上述方案，下面还提供用于实施上述方案的相关装置。

请参阅图5-a所示，本发明实施例提供的一种监控服务器500，可以包括：收集单元501、存储单元502、告警单元503，其中，

收集单元501，用于获取各个虚拟机中代理单元分别上报的监控数据，从中控服务器获取所述中控服务器对所述各个虚拟机控制时存在的监控数据；

存储单元502，将获取到的监控数据存储到数据库中；

告警单元503，用于从所述数据库中读取监控数据进行异常分析，对存在异常的监控数据进行告警；

所述存储单元502，还用于将所述存在异常的监控数据存储到所述数据库中。

在本发明的一些实施例中，请参阅如图5-b所示，相对于如图5-a所示的监控服务器，监控服务器500，还包括：展示单元504，用于所述存储单元502将所述存在异常的监控数据存储到所述数据库中之后，从所述数据库中提取出存在异常的监控数据，并向外展示以便进行故障分析。

在本发明的一些实施例中，所述收集单元501，具体用于获取各个虚拟机中代理单元按照预置的各个监控项以及收集周期实时上报的监控数据；从中控服务器获取所述中控服务器按照预置的各个监控项以及收集周期实时发送的监控数据。

在本发明的一些实施例中，所述告警单元503，具体用于根据获取到的多组监控数据进行异常分析，确定出存在异常的监控项；对确定存在异常的同一个监控项的多个异常监控数据进行聚合，按照聚合结果进行集中告警。

在本发明的一些实施例中，请参阅如图5-c所示，所述收集单元501，包括：系统收集单元5011、进程收集单元5012、模块收集单元5013、平台收集单元5014和用户收集单元5015，其中，

所述系统收集单元5011，用于接收所述各个虚拟机中代理单元分别上报的系统层数据；

所述进程收集单元5012，用于接收所述各个虚拟机中代理单元分别上报的进程层数据。

所述模块收集单元5013，用于从所述中控服务器拉取所述中控服务器通过虚拟化平台控制所述各个虚拟机时产生的模块层数据；

所述平台收集单元5014，用于从所述中控服务器拉取所述虚拟化平台的平台层数据；

所述用户收集单元5015，用于从所述中控服务器拉取用户使用虚拟机时产生的用户层数据；所述虚拟化平台上部署有多个模块，所述用户层数据包括：用户使用虚拟机时存在的虚拟机运行数据。

在本发明的一些实施例中，所述监控服务器中设置系统数据子库和进程数据子库，所述存储模块502，具体用于将所述系统层数据存储到所述系统数据子库中，将所述进程层数据存储到所述进程数据子库中；

所述监控服务器中设置模块数据子库、平台数据子库和用户数据子库， 所述存储模块502，具体用于将所述模块层数据存储到所述模块数据子库中，将所述平台层数据存储到所述平台数据子库中，将所述用户层数据存储到所述用户数据子库中。

通过以上实施例对本发明实施例的描述可知，监控服务器获取各个虚拟机中代理单元分别上报的监控数据，从中控服务器获取中控服务器对各个虚拟机控制时存在的监控数据，监控服务器将获取到的监控数据存储到数据库中，监控服务器从数据库中读取监控数据进行异常分析，对存在异常的监控数据进行告警，并将存在异常的监控数据存储到数据库中。由于监控服务器获取到的监控数据的来源包括各个虚拟机以及对虚拟机进行控制的中控服务器，监控服务器的监控面更广，覆盖到了虚拟机自身以及对各个虚拟机进行控制的中控服务器，基于从虚拟机和中控服务器收集到的监控数据进行的异常分析能够准确的确定产生异常的监控数据，并对异常的监控数据进行告警，实现了立体化全方位的监控体系。

请参阅图6所示，本发明实施例提供的一种代理单元600，所述代理单元部署在所述虚拟机中，可以包括：监控子单元601和发送子单元602，其中，

所述监控子单元601，用于监控虚拟机，根据所述虚拟机的运行数据产生监控数据，

所述发送子单元602，用于向监控服务器上报所述监控数据。

在本发明的一些实施例中，所述监控子单元601，具体用于根据配置文件设置的监控项对所述虚拟机的各项运行数据分别进行实时监控，按照所述配置文件设置的收集周期产生多组的监控数据。

在本发明的一些实施例中，所述监控数据，包括：系统层数据和进程层数据；所述发送子单元602，具体用于向所述监控服务器中设置的系统收集单元发送所述系统层数据，向所述监控服务器中设置的进程收集单元发送所述进程层数据。

通过以上实施例对本发明实施例的描述可知，各个虚拟机中代理单元分别向监控服务器上报的监控数据，监控服务器还从中控服务器获取中控服务器对各个虚拟机控制时存在的监控数据，监控服务器将获取到的监控数据存储到数据库中，监控服务器从数据库中读取监控数据进行异常分析，对存在 异常的监控数据进行告警，并将存在异常的监控数据存储到数据库中。由于监控服务器获取到的监控数据的来源包括各个虚拟机以及对虚拟机进行控制的中控服务器，监控服务器的监控面更广，覆盖到了虚拟机自身以及对各个虚拟机进行控制的中控服务器，基于从虚拟机和中控服务器收集到的监控数据进行的异常分析能够准确的确定产生异常的监控数据，并对异常的监控数据进行告警，实现了立体化全方位的监控体系。

请参阅图7所示，本发明实施例提供的一种中控服务器700，可以包括：数据生成单元701和发送单元702，其中，

所述数据生成单元701，用于产生在对各个虚拟机进行控制时的监控数据；

所述发送单元702，用于根据监控服务器的请求向所述监控服务器发送所述监控数据。

在本发明的一些实施例中，所述数据生成单元701，具体用于根据配置文件设置的监控项以及收集周期分别产生多组的监控数据。

在本发明的一些实施例中，所述监控数据，包括：模块层数据、平台层数据和用户层数据；所述发送单元702，具体用于向所述监控服务器中设置的模块收集单元发送所述模块层数据，向所述监控服务器中设置的平台收集单元发送所述平台层数据，向所述监控服务器中设置的用户收集单元发送所述用户层数据。

通过以上实施例对本发明实施例的描述可知，中控服务器向监控服务器发送中控服务器对各个虚拟机控制时存在的监控数据，监控服务器还获取各个虚拟机中代理单元分别上报的监控数据，监控服务器将获取到的监控数据存储到数据库中，监控服务器从数据库中读取监控数据进行异常分析，对存在异常的监控数据进行告警，并将存在异常的监控数据存储到数据库中。由于监控服务器获取到的监控数据的来源包括各个虚拟机以及对虚拟机进行控制的中控服务器，监控服务器的监控面更广，覆盖到了虚拟机自身以及对各个虚拟机进行控制的中控服务器，基于从虚拟机和中控服务器收集到的监控数据进行的异常分析能够准确的确定产生异常的监控数据，并对异常的监控数据进行告警，实现了立体化全方位的监控体系。

图8是本发明实施例提供的一种监控服务器结构示意图，该监控服务器800可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)822(例如，一个或一个以上处理器)和存储器832，一个或一个以上存储应用程序842或数据844的存储介质830(例如一个或一个以上海量存储设备)。其中，存储器832和存储介质830可以是短暂存储或持久存储。存储在存储介质830的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器822可以设置为与存储介质830通信，在监控服务器800上执行存储介质830中的一系列指令操作。

监控服务器800还可以包括一个或一个以上电源826，一个或一个以上有线或无线网络接口850，一个或一个以上输入输出接口858，和/或，一个或一个以上操作系统841，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述实施例中由监控服务器所执行的步骤可以基于该图5-a、图5-b、图5-c所示的监控服务器结构。

图9是本发明实施例提供的一种虚拟机结构示意图，该虚拟机900可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)922(例如，一个或一个以上处理器)和存储器932，一个或一个以上存储应用程序942或数据944的存储介质930(例如一个或一个以上海量存储设备)。其中，存储器932和存储介质930可以是短暂存储或持久存储。存储在存储介质930的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器922可以设置为与存储介质930通信，在虚拟机900上执行存储介质930中的一系列指令操作。

虚拟机900还可以包括一个或一个以上电源926，一个或一个以上有线或无线网络接口950，一个或一个以上输入输出接口958，和/或，一个或一个以上操作系统941，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述实施例中由虚拟机所执行的步骤可以基于该图6所示的代理单元结 构。

图10是本发明实施例提供的一种中控服务器结构示意图，该中控服务器1000可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)1022(例如，一个或一个以上处理器)和存储器1032，一个或一个以上存储应用程序1042或数据1044的存储介质1030(例如一个或一个以上海量存储设备)。其中，存储器1032和存储介质1030可以是短暂存储或持久存储。存储在存储介质1030的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1022可以设置为与存储介质1030通信，在中控服务器1000上执行存储介质1030中的一系列指令操作。

中控服务器1000还可以包括一个或一个以上电源1026，一个或一个以上有线或无线网络接口1050，一个或一个以上输入输出接口1058，和/或，一个或一个以上操作系统1041，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述实施例中由中控服务器所执行的步骤可以基于该图7所示的中控服务器结构。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本发明提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、 数字电路或专用电路等。但是，对本发明而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

综上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照上述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对上述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。