一种监控部署的方法以及装置与流程

本申请涉及计算机应用技术领域，具体涉及一种监控部署的方法以及一种监控部署的装置。

背景技术：

监控部署主要指当一个服务上线对外部进行服务时，需要对该服务部署对应的监控来即时发现服务的状态。目前，监控部署的多采用如下方案：根据监控指标部署对应监控项，这种部署方式适用于一次性部署的监控，若监控指标的数目众多时，根据监控指标部署对应监控项的过程就非常复杂，例如：当某个具有众多监控指标的服务上线时需要部署数目众多的监控项，在这种场景下部署时容易造成遗漏，而且逐一部署工作量巨大；或根据监控模板部署监控项，这种部署方式适用于确定性的应用部署,例如：一组机器部署了a应用，使用一套监控模板来部署a应用的监控，同时在另外一组机器也同样部署了a应用，那么可以使用同一套监控模板来部署对应的监控，且该应用的监控指标的数目众多时，可以通过监控模板来降低部署工作量，但这种方案应用在大型混合云场景下就会失效，在大型混合云场景下提供同一种服务时可以有不同的应用模块组合，部署的方案有可能都是不同的，例如：在公有云存储服务的场景下，该服务会由存储模块和计费模块组成，在私有云场景下，则只由存储模块组成。另外，在大型混合云场景下线上的应用模块的组合复杂且数量众多，在这种场景下监控模板已经无法覆盖。

由此可见，根据监控指标部署对应监控项，由于在大规模的混合云中应用模块复杂数目众多，非常容易在部署中漏掉其中一两个监控指标，漏掉的指标会导致线上出问题后无法得到报警从而造成故障，为了解决根据监控指标部署对应监控项的遗漏问题，出现使用监控模板来部署监控的方案，然而这个方案在混合云运维的场景中由于有非常多的应用模块组合也无法工作，使用现有的监控部署方案对于应用部署监控变成一个非常复杂的过程。所以在现有的监控部署方案下，无法适应混合云场景下多种模块组合的部署，部署成本高并且容易出错，且在出错后无法对监控部署正确性进行校验，而且在混合云中林林总总的网络设备、服务器、中间件、数据库、业务系统等不同设备需要不同用户来进行配置，不熟悉部署方式的用户无法完整部署对应监控，从而使得部署实施团队规模较大，效率低，集群配置人工成本较高，配置复杂、容易出现错误，导致正常的部署延迟，为部署工作带来障碍。

技术实现要素：

本申请提供一种监控部署的方法以及一种监控部署的装置,以解决现有技术中的上述问题。

本申请提供了一种监控部署的方法，所述监控部署的方法，包括：

获取机器中的角色信息；

根据所述角色信息创建对应的监控模板；

根据所述监控模板为所述机器部署监控。

可选的，所述获取机器中的角色信息，包括：

根据所述机器的进程获取机器中的角色信息。

可选的，在所述获取机器中的角色信息的步骤之后，包括：

将所述角色信息存储在第一数据库中。

可选的，所述根据所述角色信息创建对应的监控模板，包括：

对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板。

可选的，所述对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板，包括：

获取所述角色信息对应的应用模块；

为所述应用模块创建监控模板；

为所述应用模块的外部依赖创建监控模板；

为所述应用模块对应的系统创建监控模板；

为所述应用模块对应的机器创建监控模板；

将上述监控模板作为所述角色信息的监控模板。

可选的，所述监控项，包括：监控脚本、监控阈值以及报警方式。

可选的，所述监控阈值是根据该监控项监控的历史数据信息确定。

可选的，在所述对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板的步骤之后，包括：

将创建的所述监控模板存储在第二数据库中。

可选的，在所述对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板的步骤之后，还包括：

为所述角色信息与对应的监控模板创建映射关系；

将所述映射关系存储在在第一数据库中。

可选的，在所述根据所述监控模板为所述机器部署监控的步骤之后，包括：

根据所述机器中的角色信息，查询第一数据库中与所述机器中的角色信息相同的映射关系；

在第二数据库中获取对应所述映射关系的监控模板；

判断所述机器中部署的监控是否与获取的监控模板相同；

若否，则根据所述监控模板为所述机器部署监控。

相应的，本申请还提供了一种监控部署的装置，所述监控部署的装置，包括：

角色信息获取单元，用于获取机器中的角色信息；

监控模板创建单元，用于根据所述角色信息创建对应的监控模板；

监控部署单元，用于根据所述监控模板为所述机器部署监控。

可选的，所述角色信息获取单元，具体用于根据所述机器的进程获取机器中的角色信息。

可选的，所述监控部署的装置，还包括：

角色信息存储单元，用于在所述获取机器中的角色信息之后，将所述角色信息存储在第一数据库中。

可选的，所述监控模板创建单元，具体用于对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板。

可选的，所述监控模板创建单元，包括：

应用获取子单元，用于获取所述角色信息对应的应用模块；

应用监控项创建子单元，用于为所述应用模块创建监控模板；

外部监控项创建子单元，用于为所述应用模块的外部依赖创建监控模板；

系统监控项创建子单元，用于为所述应用模块对应的系统创建监控模板；

机器监控项创建子单元，用于为所述应用模块对应的机器创建监控模板；

监控模板创建子单元，用于将上述监控模板作为所述角色信息的监控模板。

可选的，所述监控项创建子单元、所述外部监控项创建子单元、所述系统监控项创建子单元以及机器监控项创建子单元创建的监控项包括：监控脚本、监控阈值以及报警方式。

可选的，所述监控模板创建单元，还包括：

监控阈值生成子单元，用于根据所述监控项监控的历史数据信息确定监控阈值。

可选的，所述监控部署的装置，还包括：

监控模板存储单元，用于在所述对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板之后，将创建的所述监控模板存储在第二数据库中。

可选的，所述监控部署的装置，还包括：

映射创建单元，用于在所述对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板之后，为所述角色信息与对应的监控模板创建映射关系；

映射存储单元，用于将所述映射关系存储在在第一数据库中。

可选的，所述监控部署的装置，还包括：

映射查询单元，用于所述根据所述监控模板为所述机器部署监控之后，根据所述机器中的角色信息，查询第一数据库中与所述机器中的角色信息相同的映射关系；

映射获取单元，用于在第二数据库中获取对应所述映射关系的监控模板；

监控模板判断单元，用于判断所述机器中部署的监控是否与获取的监控模板相同；

重新部署单元，用于接收所述监控模板判断单元的判断结果，若否，则根据所述监控模板为所述机器部署监控。

与现有技术相比，本申请具有以下优点：

本申请提供的一种监控部署的方法以及一种监控部署的装置，通过获取机器中的角色信息；根据所述角色信息创建对应的监控模板；根据所述监控模板为所述机器部署监控。所述技术方案通过对角色信息创建对应的监控模板，根据应用部署中的服务进行灵活组合，能够适应各种模块组合的部署场景，解决了在大规模混合云运维场景下监控部署复杂、监控部署无法根据复杂场景灵活组合的问题，降低部署成本，且根据角色信息进行划分创建监控模版后任何用户都可部署相应的监控，降低集群配置人工成本，提高效率，并由于监控标准化，且对服务定义角色，便于对于监控是否正确部署，监控是否有遗漏进行检查，防止监控遗漏问题，降低了出错的概率。

附图说明

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

图1示出了根据本申请的实施例提供的监控部署的方法的流程图；

图2示出了根据本申请的实施例提供的对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板的流程图；

图3示出了根据本申请的实施例提供的创建映射关系的流程图；

图4示出了根据本申请的实施例提供的检查机器中部署的监控的流程图；

图5示出了根据本申请的实施例提供的监控部署的装置的示意图。

具体实施方式

为了能够更清楚地理解本申请的上述目的、特征和优点，下面结合附图和具体实施方式对本申请进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是，本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此，本申请不受下面公开的具体实施的限制。

本申请的实施例提供了一种监控部署的方法以及一种监控部署的装置。在下面的实施例中逐一进行详细说明。

目前，根据监控指标部署对应监控项，由于在大规模的混合云中应用模块复杂数目众多，非常容易在部署中漏掉其中一两个监控指标，漏掉的指标会导致线上出问题后无法得到报警从而造成故障，为了解决根据监控指标部署对应监控项的遗漏问题，出现使用监控模板来部署监控的方案，然而这个方案在混合云运维的场景中由于有非常多的应用模块组合也无法工作，使现有的监控部署方案对于应用部署监控变成一个非常复杂的过程。所以在现有的监控部署方案下，无法适应混合云场景下多种模块组合的部署，部署成本高并且容易出错，且在出错后无法对监控部署正确性进行校验，而且在混合云中林林总总的网络设备、服务器、中间件、数据库、业务系统等不同设备需要不同用户来进行配置，不熟悉部署方式的用户无法完整部署对应监控，从而使得部署实施团队规模较大，效率低，集群配置人工成本较高，配置复杂、容易出现错误，导致正常的部署延迟，为部署工作带来障碍。针对这一问题，本申请的技术方案通过通过对角色信息创建对应的监控模板，根据应用部署中的服务进行灵活组合，能够适应各种模块组合的部署场景，从而解决了在大规模混合云运维场景下监控部署复杂、监控部署无法根据复杂场景灵活组合的问题，并降低部署成本，且根据角色信息进行划分创建监控模版后任何用户都可部署相应的监控，降低集群配置人工成本，提高效率，并由于监控标准化，且对服务定义角色，便于对于监控是否正确部署，监控是否有遗漏进行检查，防止监控遗漏问题，降低了出错的概率。

在详细描述本实施例的具体步骤之前，为了方便对本技术方案的理解，先对现有的监控部署作简要说明。

监控部署(monitordeployment)是指：当一个服务上线对外部服务时，需要对该服务部署对应的监控来即时发现服务的状态，监控部署即对上线应用部署对应正确性检测代码的行为。

对服务进行监控是指：线上应用上线对外服务之后，需要对该服务进行正确性和健康性的检测，当服务外部环境或者内部应用出现异常之后能够及时发现的一种手段。

部署是指：将应用程序升级包同步到每一台机器上，在每台机器上执行相同的解包，备份，停止，更新，启动等步骤，并手动编辑需要配置的每一个配置文件。

本申请的实施例提供了一种监控部署的方法，其目的是解决混合云场景下多种模块组合的部署问题，该方法通过对角色信息创建对应的监控模板，根据应用部署中的服务进行灵活组合，能够适应各种模块组合的部署场景，从而解决了在大规模混合云运维场景下监控部署复杂、监控部署无法根据复杂场景灵活组合的问题。所述监控部署的方法实施例如下：

请参考图1，其示出了根据本申请的实施例提供的监控部署的方法的流程图。

所述监控部署的方法包括：

步骤s101，获取机器中的角色信息。

在本实施例中，所述获取机器中的角色信息，可以采用如下方式实现：获取运行在所述机器中的应用模块，将获取的应用模块作为所述机器中的角色，并获取所述角色的角色信息。

例如：在所述机器a中获取到运行在所述机器a中的应用模块为nginx、a_server和计费服务(quota)，则将应用模块nginx、应用模块a_server以及应用模块quota作为所述机器a中的角色，将应用模块nginx定义为角色role_nginx、将应用模块a_server定义为角色role_a_server以及将应用模块quota定义为角色role_quota，并获取上述角色的角色信息role_nginx、role_a_server以及role_quota。

需要说明的是，角色(role)是指:一种对服务器提供的服务能力进行描述的标签。本申请提供的技术方案是针对于应用模块(即实际监控的监控对象)来设置角色，与软件编程开发程序中对于机器的角色的定义不同，角色的定义依据是运行在机器中的应用模块。例如：一台http服务器，对其角色定义为role_webserver。

在本实施例中，所述机器是在混合云中运行的服务器，服务器是面向各类互联网用户提供总和业务能力的服务平台，使数据能够集中管理，让若干终端用户共用一台主机。在机器中可以部署一个或多个服务，每个服务由多个应用模块实现。

需要说明的是，在本实施例中，应用模块nginx还可以使用应用模块apache。apache(httpserver)是一个开放源码的模块化的网页服务器，可以在大多数计算机操作系统中运行，由于其多平台和安全性被广泛使用，是最流行的web服务器端软件之一。它快速、可靠并且可通过简单的api扩展，将perl/python等解释器编译到服务器中。也不排除随着技术进步使用其它新出现的服务器软件，在此不作限定。

可以理解的，若在机器中包含多个服务，例如：2个服务，则在所述机器中服务1的应用模块为nginx、a_server和计费服务(quota)，服务2的应用模块为nginx以及b_server，则将应用模块nginx、应用模块a_server、应用模块quota以及应用模块b_server作为所述机器a中的角色，将服务1中的应用模块nginx定义为角色role_nginx、将应用模块a_server定义为角色role_a_server以及将应用模块quota定义为角色role_quota，将服务2中的应用模块nginx定义为角色role_nginx以及将应用模块b_server定义为角色role_b_server，并获取上述角色的角色信息role_nginx、role_a_server、role_b_server以及role_quota。

需要说明的是，当机器中具有多个服务时，且不同服务之间具有相同的应用模块时，在获取机器中的角色信息后，会去除角色名称相同的角色信息。例如：在服务1和服务2中的应用模块为nginx。

nginx是一个高性能的web和反向代理服务器及电子邮件(imap/pop3/smtp)代理服务器。nginx其特点是占有内存少，并发能力强，和它的稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名。

在具体实施时，所述获取机器中的角色信息是根据所述机器的进程获取机器中的角色信息。

需要说明的是，进程是服务器中的应用程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。在早期面向进程设计的结构中，进程是应用程序的基本执行实体；在当代面向线程设计的结构中，进程是线程的容器。应用程序是指令、数据及其组织形式的描述，进程是应用程序的实体，所以所述机器的进程就是实际在该机器中正在运行的应用模块的实例，能够根据所述机器的进程获取到机器中的角色的角色信息。

在本实施例中，在执行步骤s101获取机器中的角色信息后，由于当前获取到的所述角色信息是存储在内存中的数据，则需要对获取到的所述角色信息进行持久化处理，所以本实施例的技术方案提供了一种优选实施方式，在优选方式下，在所述获取机器中的角色信息的步骤之后，将所述角色信息存储在第一数据库中。

需要说明的是，所述第一数据库是配置管理数据库(cmdb)，该数据库用于存储与管理企业it架构中设备的各种配置信息的数据库，包括基础设施、应用属性等信息。

可以理解的，持久化(persistence)是将数据信息在持久状态和瞬时状态间转换的机制。即把数据信息(例如内存中的数据，是不能永久保存的)持久化为持久数据(例如持久化至可永久保存的存储设备中，能够长久保存)持久化的主要应用是将内存中的对象存储在的数据库中，或者存储在磁盘文件中、xml数据文件中等。

例如：在配置管理数据库中存储角色信息时，在一台机器中，如果只部署了a_server，则在cmdb中记录为[role_a_server],如果只部署了b_server，在cmdb中记录为[role_b_server]，如果同时部署了a_server和b_server，那么在cmdb中记录为[role_a_server,role_b_server]。

步骤s103，根据所述角色信息创建对应的监控模板。

在本实施例中，所述监控模板是指：由若干监控项组成的组合，当对一个应用模块进行监控时，如果将多个监控项存储到一个监控模板中时，只需部署一个监控模板就能同时将该监控模板中的多个监控项部署到应用上。

其中，所述监控项是由监控脚本、监控阈值以及报警方式组合成的整体，将监控脚本、监控阈值以及报警方式组合在一起才能对具体的应用模块进行有效的监控。监控脚本负责对应用模块中的指标数据进行采集，监控阈值是对上述指标数据预先设置的判断该指标数据是否异常的数值，当监控脚本采集的指标数据的数值超过预先设置的监控阈值时，则判断该指标数据发生异常，报警方式是当监控脚本采集到的指标数据超过预先设置的监控阈值时，采用的向系统或用户进行报警通知的途径。

具体的，所述监控脚本是对线上服务的一个指标做对应监控的代码，例如：对服务器的硬盘进行监控的硬盘监控代码为硬盘监控脚本，对服务可用性进行监控的为服务可用性监控脚本。

报警方式是一个指标数据异常之后根据具体的异常情况对相应的目标(系统或用户)进行报警通知的途径。例如：当指标数据为warning时，那么对这个报警设置的目标(用户)选择对应的报警行为(向用户预留在系统中的手机号码发送短信)。

可以理解的，当一个服务中包含4个应用模块时，由于4个应用模块有不同的需求而组成多种不同的组合，在实际工作中4个应用模块的组合最多有可能会产生c(4,1)+c(4,2)+c(4,3)+c(4,4)＝15种应用模块的组合，所以若直接使用监控模板时，单单4种应用模块的组合就需要15种监控模板，而在混合云的应用场景下，实际服务中的应用模块则更多，所以本技术方案是针对每个单一的应用模块进行监控而不是他们的组合。

在本实施例中，所述根据所述角色信息创建对应的监控模板，可以采用如下方式实现：根据已获取到的所述角色信息，为每一角色创建对应该角色的监控模板。

例如：在步骤s101中获取到的机器a中的角色信息为role_nginx、role_a_server以及role_quota，则在本步骤中为角色role_nginx创建对应的的监控模板、为角色role_a_server创建对应的的监控模板以及为角色role_quota创建对应的的监控模板。

具体的，所述根据所述角色信息创建对应的监控模板，是对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板。

其中，所述应用模块的监控模板是针对具体服务中的应用模块进行的监控，每个应用模块有自己的应用监控，与其他应用没有重叠关系；

所述组件模块的监控模板是指对服务使用的中间件组件进行的监控是创建的监控模板，服务在上线时，有可能会使用到中间件组件，所述组件模块的监控模板是对使用了中间件的服务进行的监控；

所述系统模块的监控模板是对机器及在机器中运行的与当前角色相关的服务器软件进行的监控，例如：对机器的cpu，内存，硬盘等进行监控。

可以理解的，在对具体的角色创建对应的监控模板时，对于监控系统而言，不仅仅是对角色对应的应用模块进行监控，还涉及到对于机器硬件(cpu,内存，硬盘，网卡等硬件监控)、软件系统(内核参数，系统运行状态)、外部依赖(监控对象的外部依赖)的监控，所以所述对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板，具体包括步骤s103-1至s103-6，下面结合附图2作进一步说明。

请参考图2，其示出了根据本申请的实施例提供的对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板的流程图。

所述对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板，包括：

步骤s103-1，获取所述角色信息对应的应用模块。

在本实施例中，所述角色信息是将机器中运行的应用模块作为所述机器中的角色，并获取所述角色的角色信息，所以在本步骤中可以通过所述角色信息直接确定该角色信息对应的应用模块。

例如：对角色信息role_a_server创建对应的监控模板时，在本步骤中就是获取所述角色信息role_a_server对应的应用模块a_server。

步骤s103-2，为所述应用模块创建监控模板。

在本实施例中，所述为所述应用模块创建监控模板，可以采用如下方式实现：确定所述应用模块需要监控的指标，根据所述指标为所述应用模块确定相应的监控脚本，并为所述指标预先设置监控阈值，并设置监控脚本采集的指标数据超过预先设置的监控阈值时的报警方式。

需要说明的是，所述预先设置的监控阈值是根据监控脚本采集到的历史指标数据进行设置的，即：使不同的应用模块根据对应该应用模块已经采集到的历史指标数据自识别该应用模块监控项的监控阈值。

例如：所述应用模块a_server需要监控的指标有3个，则为该应用模块a_server确定三个对应指标的监控脚本，并设置三个监控阈值以及超过所述监控阈值时的报警方式，则每组监控脚本、监控阈值以及报警方式组成该应用模块a_server的一组监控项，所以为所述应用模块a_server创建监控模板中具有3组监控项(a_server监控1、a_server监控2以及a_server监控3)。

可以理解的，在本步骤中创建的是应用模块的监控模板。

步骤s103-3，为所述应用模块的外部依赖创建监控模板。

在本实施例中，所述为所述应用模块的外部依赖创建监控模板，可以采用如下方式实现：确定所述应用模块的外部依赖需要监控的指标，根据所述指标为所述应用模块的外部依赖确定相应的监控脚本，并为所述指标预先设置监控阈值，并设置监控脚本采集的指标数据超过预先设置的监控阈值时的报警方式。

需要说明的是，所述预先设置的监控阈值是根据监控脚本采集到的历史指标数据进行设置的，即：使不同的应用模块的外部依赖根据对应该外部依赖已经采集到的历史指标数据自识别该外部依赖的监控阈值。

例如：所述应用模块a_server的外部依赖需要监控的指标有3个，则为该应用模块的外部依赖确定三个对应指标的监控脚本，并设置三个监控阈值以及超过所述监控阈值时的报警方式，则每组监控脚本、监控阈值以及报警方式组成该应用模块的外部依赖的一组监控项，所以为所述应用模块的外部依赖创建监控模板中具有3组监控项(应用通用组件监控1、应用通用组件监控2以及应用通用组件监控3)。

需要说明的是，所述应用模块的外部依赖指的是中间件。中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。中间件位于客户机/服务器的操作系统之上，管理计算机资源和网络通讯。是连接两个独立应用程序或独立系统的软件，它包括一组服务。以便于运行在一台或多台机器上的多个软件通过网络进行交互。

可以理解的，在本步骤中创建的是应用通用组件的监控模板。

步骤s103-4，为所述应用模块对应的系统创建监控模板。

在本实施例中，所述为所述应用模块对应的系统创建监控模板，可以采用如下方式实现：确定所述应用模块对应的系统需要监控的指标，根据所述指标为所述应用模块对应的系统确定相应的监控脚本，并为所述指标预先设置监控阈值，并设置监控脚本采集的指标数据超过预先设置的监控阈值时的报警方式。

需要说明的是，所述预先设置的监控阈值是根据监控脚本采集到的历史指标数据进行设置的，即：使不同的系统根据对应该系统已经采集到的历史指标数据自识别该系统的监控阈值。

例如：所述应用模块a_server对应的系统需要监控的指标有3个，则为该应用模块对应的系统确定三个对应指标的监控脚本，并设置三个监控阈值以及超过所述监控阈值时的报警方式，则每组监控脚本、监控阈值以及报警方式组成该应用模块对应的系统的一组监控项，所以为所述应用模块对应的系统创建监控模板中具有3组监控项(系统组件监控1、系统组件监控2以及系统组件监控3)。

可以理解的，在本步骤中创建的是线上基础组件的监控模板。

步骤s103-5，为所述应用模块对应的机器创建监控模板。

在本实施例中，所述为所述应用模块对应的机器创建监控模板，可以采用如下方式实现：确定所述应用模块对应的机器需要监控的指标，根据所述指标为所述应用模块对应的机器确定相应的监控脚本，并为所述指标预先设置监控阈值，并设置监控脚本采集的指标数据超过预先设置的监控阈值时的报警方式。

需要说明的是，所述预先设置的监控阈值是根据监控脚本采集到的历史指标数据进行设置的，即：使不同的机器根据对应该机器已经采集到的历史指标数据自识别该机器的监控阈值。

例如：根据业务的属性设置相应的监控阈值，当机器需要监控的网卡时，则通过监控脚本采集到网卡在使用时的历史指标数据，根据使用时段进行判断当处于网卡使用的高峰期时将提高所述监控阈值的数值，当处于网卡使用的低峰期时将降低所述监控阈值的数值。

具体的，为所述应用模块对应的机器创建监控模板时，所述应用模块a_server对应的机器至少需要监控cpu、硬盘、网卡、内存，则为该应用模块对应的机器确定四个对应采集cpu、硬盘、网卡、内存使用量数值的监控脚本，并设置四个监控阈值以及超过所述监控阈值时的报警方式，则每组监控脚本、监控阈值以及报警方式组成该应用模块对应的系统的一组监控项，所以为所述应用模块对应的机器创建监控模板中具有4组监控项(cpu控、硬盘控、网卡控、内存控)。

需要说明的是，在机器中设置多个服务a_server和b_server时，在本步骤中对机器的监控就是公共的，若对于不同的应用模块进行监控模板的抽离，会产生如下两类问题：一是公共监控的冲突，即：一台机器上部署了多个相同的监控(cpu、硬盘、网卡、内存的监控)，如果不支持两个相同的监控部署，则监控模板无法工作，即使支持相同的监控部署，如果两个相同监控采集的指标数据不一致，就会造成失效及误报；二是由于每个监控模版在设置时，都需要对监控项中进行设置，例如对监控阈值进行设置，设置监控成本高。所以在本实施例中，为解决上述问题采用mixin将公共部分进行抽离。

需要说明的是，mixin是一种编程中的概念，可以将多个类中的功能单元的进行组合利用的一种方式，是与面对对象中类继承不同的功能复用的方式。

mixin不会对进行组合的模块造成影响，只是在需要时将多个模块中的功能进行组合来完成功能。

可以理解的，在本步骤中创建的是系统公共组件的监控模板。

步骤s103-6，将上述监控模板作为所述角色信息的监控模板。

在本实施例中，所述将上述监控模板作为所述角色信息的监控模板，可以采用如下方式实现：将步骤s103-2至步骤s103-5中创建的应用模块的监控模板、应用通用组件的监控模板、线上基础组件的监控模板以及系统公共组件的监控模板功能进行合并，将合并后的监控模板作为所述角色信息的监控模板。

需要说明的是，由于监控模板是由至少一个监控项组成的，所以在合并监控模板时，就是将每个监控模板中的监控项提取出，并组合成一个新的监控模板。

在本实施例中，由于创建的所述角色信息的监控模板是存储在内存中的数据，则需要对已创建的监控模板进行持久化处理，所以本实施例的技术方案提供了一种优选实施方式，在优选方式下，在所述对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板之后，将创建的所述监控模板存储在第二数据库中。

需要说明的是，所述第二数据库是监控模板库，该数据库用于存储生成的各种角色信息的监控模板。

由于所述角色信息是存储在第一数据库中，所述角色信息的监控模板是存储在第二数据库中，所述角色信息和所述角色信息的监控模板是分开存储的，所以在所述对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板的之后，并在存储后建立与第一数据库中存储的对应角色信息的映射关系，具体包括步骤s104-1至s104-2，下面结合附图3作进一步说明。

请参考图3，其图3示出了根据本申请的实施例提供的创建映射关系的流程图。

所述创建映射关系，包括：

步骤s104-1，为所述角色信息与对应的监控模板创建映射关系。

在本实施例中，所述为所述角色信息与对应的监控模板创建映射关系，可以采用如下方式实现：为已存储在第一数据库中的角色信息建立与存储在第二数据库中对应所述角色信息的监控模板之间的映射关系。

步骤s104-2，将所述映射关系存储在在第一数据库中。

在本实施例中，在创建所述角色信息与对应的监控模板之间的映射关系后，将创建出的所述映射关系存储在在第一数据库中。

可以理解的，通过将应用模块与监控模板的关系转化为角色与监控模板的对应关系(映射关系)，使用户只需要获取机器中的角色，就可以部署对应的角色的监控模板，即可部署出完整的监控，降低集群配置人工成本，提高部署效率。

步骤s105，根据所述监控模板为所述机器部署监控。

在本实施例中，所述根据所述监控模板为所述机器部署监控，可以采用如下方式实现：根据在所述机器中已获取的角色信息，确定需要部署在所述机器中的监控模板，根据所述监控模板在所述机器中部署相应的监控。

具体的，所述根据所述监控模板为所述机器部署监控是：根据在所述机器中已获取的全部角色信息，查询第一数据库中存储的在所述机器中角色信息与对应的监控模板创建映射关系，获取需要部署在所述机器中的全部监控模板，并根据所述监控模板在所述机器中部署相应的监控。

需要说明的是，部署监控是在机器上线之后进行的操作，所以在执行本步骤时，是在所述机器中为全部角色部署监控，例如：若在所述机器中只部署了a_server服务，则对应a_server的监控模板为：应用模块a_server的监控模板、应用通用组件的监控模板、线上基础组件的监控模板以及系统公共组件的监控模板；若在所述机器中只部署了b_server服务，则对应b_server的监控模板为：应用模块b_server的监控模板、应用通用组件的监控模板、线上基础组件的监控模板以及系统公共组件的监控模板；若在所述机器中同时部署了a_server服务以及b_server服务，则将对应a_server的监控模板与对应b_server的监控模板进行合并，则合并后的监控模板为：应用模块a_server的监控模板、应用模块b_server的监控模板应用通用组件的监控模板、线上基础组件的监控模板以及系统公共组件的监控模板。

可以理解的，由于a_server服务和b_server服务的外部依赖不同，则各自的应用通用组件的监控模板也会不同，所以在上述对监控模块进行合并时，还需要对各自的应用通用组件的监控模板中的监控项进行合并，生成新的应用通用组件的监控模板。

在对所述机器部署监控后，由于对所述机器部署了监控，所以还需要对部署了的监控进行正确性进行校验，所以在所述根据所述监控模板为所述机器部署监控的步骤之后，具体包括步骤s106至s109，下面结合附图4作进一步说明。

请参考图4，其示出了根据本申请的实施例提供的检查机器中部署的监控的流程图。

所述检查机器中部署的监控，包括：

步骤s106，根据所述机器中的角色信息，查询第一数据库中与所述机器中的角色信息相同的映射关系。

在本实施例中，所述根据所述机器中的角色信息，查询第一数据库中与所述机器中的角色信息相同的映射关系，可以采用如下方式实现：获取已部署监控的机器中的角色信息，查询第一数据库中存储的与获取的所述角色信息相同的角色信息与对应的监控模板之间的映射关系。

在本步骤中，获取所述机器中的角色信息是根据所述机器的进程获取机器中的角色信息。

步骤s107，在第二数据库中获取对应所述映射关系的监控模板。

在本实施例中，所述在第二数据库中获取对应所述映射关系的监控模板，可以采用如下方式实现：根据已获取到的映射关系，在所述第二数据库中查询并获取所述映射关系中的监控模板。

步骤s108，判断所述机器中部署的监控是否与获取的监控模板相同。

在本实施例中，所述判断所述机器中部署的监控是否与获取的监控模板相同，可以采用如下方式实现：对所述机器中部署的监控进行规则检查，判断在所述机器中部署的监控是否与已获取的监控模板相同。

步骤s109，若否，则根据所述监控模板为所述机器部署监控。

本步骤接收步骤s108中的判断结果，若所述机器中部署的监控与获取的监控模板不相同，则说明所述机器在部署时，遗漏了部分监控没有部署在所述机器上，则会触发执行所述则根据所述监控模板为所述机器部署监控。所述根据所述监控模板为所述机器部署监控是指：根据所述监控模板重新在所述机器中进行部署监控。

可以理解的，通过将机器的角色(role)信息记录在应用的第一数据库中，对所有机器获取对应的角色(role)信息后，通过角色信息与监控模板的映射关系即可获取所述机器的全部监控模板，通过已获取的全部监控模板与机器中际部署的监控模板做比较，从而实现了检查机器中部署的监控的功能。

在上述的实施例中，提供了一种监控部署的方法，与上述监控部署的方法相对应的，本申请还提供了一种监控部署的装置。由于装置的实施例基本相似于方法的实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。下述描述的装置实施例仅仅是示意性的。所述监控部署的装置实施例如下：

请参考图5，其示出了根据本申请的实施例提供的监控部署的装置的示意图。

所述监控部署的装置，包括：角色信息获取单元501、监控模板创建单元503以及监控部署单元505；

所述角色信息获取单元501，用于获取机器中的角色信息；

所述监控模板创建单元503，用于根据所述角色信息创建对应的监控模板；

所述监控部署单元505，用于根据所述监控模板为所述机器部署监控。

可选的，所述角色信息获取单元501，具体用于根据所述机器的进程获取机器中的角色信息。

可选的，所述监控部署的装置，还包括：角色信息存储单元；

所述角色信息存储单元，用于在所述获取机器中的角色信息之后，将所述角色信息存储在第一数据库中。

可选的，所述监控模板创建单元503，具体用于对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板。

可选的，所述监控模板创建单元503，包括：应用获取子单元、应用监控项创建子单元、外部监控项创建子单元、系统监控项创建子单元、机器监控项创建子单元以及监控模板创建子单元；

所述应用获取子单元，用于获取所述角色信息对应的应用模块；

所述应用监控项创建子单元，用于为所述应用模块创建监控模板；

所述外部监控项创建子单元，用于为所述应用模块的外部依赖创建监控模板；

所述系统监控项创建子单元，用于为所述应用模块对应的系统创建监控模板；

所述机器监控项创建子单元，用于为所述应用模块对应的机器创建监控模板；

所述监控模板创建子单元，用于将上述监控模板作为所述角色信息的监控模板。

可选的，所述监控项创建子单元、所述外部监控项创建子单元、所述系统监控项创建子单元以及机器监控项创建子单元创建的监控项包括：监控脚本、监控阈值以及报警方式。

可选的，所述监控模板创建单元503，还包括：监控阈值生成子单元；

所述监控阈值生成子单元，用于根据所述监控项监控的历史数据信息确定监控阈值。

可选的，所述监控部署的装置，还包括：监控模板存储单元；

所述监控模板存储单元，用于在所述对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板之后，将创建的所述监控模板存储在第二数据库中。

可选的，所述监控部署的装置，还包括：映射创建单元以及映射存储单元；

所述映射创建单元，用于在所述对所述角色信息对应的应用模块、系统模块以及组件模块创建监控模板之后，为所述角色信息与对应的监控模板创建映射关系；

所述映射存储单元，用于将所述映射关系存储在在第一数据库中。

可选的，所述监控部署的装置，还包括：映射查询单元、映射获取单元、监控模板判断单元以及重新部署单元；

所述映射查询单元，用于所述根据所述监控模板为所述机器部署监控之后，根据所述机器中的角色信息，查询第一数据库中与所述机器中的角色信息相同的映射关系；

所述映射获取单元，用于在第二数据库中获取对应所述映射关系的监控模板；

所述监控模板判断单元，用于判断所述机器中部署的监控是否与获取的监控模板相同；

所述重新部署单元，用于接收所述监控模板判断单元的判断结果，若否，则根据所述监控模板为所述机器部署监控。

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

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

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。