CN108009004B - 基于Docker的业务应用可用度测量监控的实现方法 - Google Patents

Abstract

本发明提供一种基于Docker的业务应用可用度测量监控的实现方法，该方法有效的实现了对业务应用可用度的监控，为业务的持续可用提供了技术支撑，有效的维护了整体业务的稳定性，实现对容器内的业务应用参数进行全面的收集、测量和存储，实现对集群内的业务应用情况进行监督。

Description

基于Docker的业务应用可用度测量监控的实现方法

技术领域

本发明涉及计算机技术领域，更具体地，涉及一种基于Docker的业务应用可用度测量监控的实现方法。

背景技术

Docker是基于Linux容器(LXC)创建的一个应用容器引擎，属于操作系统层虚拟化，主要用于服务器应用快速构建、部署和分享的问题。Docker对LXC做了一层封闭，提供更易于使用的接口，使容器的管理操作更加方便。在宏观角度看，容器更像是轻量级的虚拟化。每个容器都有自己的网络堆栈、进程空间、文件系统等，可以使用容器安装任何想要的软件，各软件独立运行，不影响其他容器和宿主机。而从底层角度看，容器只是宿主机上一个进程，利用内核特征如namespace和cgroups来提供这种隔离。

Linux容器是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源，而且不需要提供指令解释机制以及全虚拟化的其他复杂性。它可以在单台服务器中虚拟出多个相互隔离的执行环境，在容器内部执行的进程，被容器技术隔离在容器内部，对进程而言就如同运行在一台单独的服务器上，而无法感知该服务上其他容器内或者服务器上的服务。

随着Linux容器技术的普及，越来越多的业务应用被以容器的形式部署到服务器中运行，业务应用被分解成多个服务运行在多个容器中，部署在容器内部的服务，需要通过可用度测量对业务应用的可用度情况进行监控。

现有技术中至少存在如下问题：业务应用通常以多个服务的形式运行在多个容器中，业务应用的整体可用度难于测量，造成业务应用监控困难，难于保障业务应用的可持续性。

发明内容

本发明提供一种有效的基于Docker的业务应用可用度测量监控的实现方法。

为了达到上述技术效果，本发明的技术方案如下：

一种基于Docker的业务应用可用度测量监控的实现方法，包括以下步骤：

S1：搭建Docker DM搭建；

S2：构建采集模块；

S3：构建测量模块；

S4：根据不同的策略对应用进行监控；

S5：监控客户端。

进一步地，所述步骤S1的具体过程是：

1)、监控服务器：用于保存和汇总各宿主机的状态数据，同时也是提供Web图形化功能；

安装tomcat，用于提供web服务；

部署docker镜像仓库，用于提供局域网内的镜像仓库服务；

安装mysql数据库，用于数据的存储；

2)、宿主机：用于运行docker镜像的服务器，也是需要定时采集状态数据；

在监控的宿主机中通过yum命令安装docker，并修改docker的配置文件，添加局域网内的镜像仓库地址，以加快镜像的下载速度。

进一步地，所述步骤S2的具体过程是：

1)、编写shell脚本：读取Linux下的/proc目录下的对应状态文件来获取当前宿主机的CPU、内存和网络状况，并将这些数据和当前主机标识组织成json格式发送给监控服务器；在脚本中为了使得数据能尽可能地反映当前状态，需要通过几次采集后取平均值以减低瞬时数据的对数据准确度的影响；

2)、编写shell脚本：调用docker的api获取当前主机中所有容器的运行状态数据并将这些数据和当前主机标识组织成json格式发送给监控服务器；

3)、通过crontab命令为宿主机添加定时任务，定时执行上面的两个脚本来获取监控的数据。为了使得数据具有一定的实时性，设置定时任务间隔为1分钟。

进一步地，所述步骤S3的具体过程是：

1)、通过图形界面配置应用的依赖关系和应用的关联关系，应用的依赖关系即某个应用启动时，需要依赖其他应用，所以我们设置的是应用的启动顺序，在一整套的业务应用中会有多个应用，而当应用整体宕机，或者重启的时候，必须要有一定的执行顺序，这个就是应用的启动顺序和依赖关系；将该顺序进行记录并存储到数据库中；配置应用的关联关系，则是配置几个应用的关系,一套业务应用系统中往往都会有多个应用，而每个应用都是息息相关，所以要配置每一个应用和其他应用的关系，而配置的关系有必要关系和非必要关系，必须关系就是一个应用必须要在另外一个应用的基础运行的基础上才能启动，非必要关系就是指两个应用可以同级运行，没有另外一个应用，这个应用也可以单独启动；

2)、在描述完关系后，还需要对这些关系进行权值的设置，即当A应用完全依赖于B应用，当B应用不能使用，这时A应用也相应的完全不能使用，这时A依赖B的关系权值就为1；如果A不是完全不能使用，而是部分可以使用，这是可以根据影响的效果设置为小于1的权值，而这个权值将影响到后面监控过程中应用的可用度。

进一步地，所述步骤S4的具体过程是：

1)、根据不同的策略对应用进行监控：监控可以分成应用监控管理和容器监控管理。应用监控可以监控当前应用的连接数和应用的流量，当连接数和流量超过设置的最大限制后，将推送客户发出警告，容器管理监控是监控当前运行中的应用容器所占的资源，如内存和cpu使用率，当内存和cpu超过设置的使用率时，将推送客户发出警告；

2)、通过宿主机的定时任务，定时采集相关的状态数据，定时发送给监控服务器：监控服务器再收到这些数据后，按照数据中的宿主机标识将这些数据汇总到一起；在收到数据后，先对数据按照宿主机标识进行分离，并保存到数据库中；同时根据这些状态数据更新宿主机的状态和Docker应用的状态，并且根据应用的依赖关系，按照当前最新的状态与权值，计算出当前应用的可用度，并将这个数据保存到数据库中。

进一步地，所述步骤S5的具体过程是：

在监控客户端中，通过图形化的展示方式进行展示应用的拓扑关系、可用度和监控数据。

与现有技术相比，本发明技术方案的有益效果是：

本发明方法有效的实现了对业务应用可用度的监控，为业务的持续可用提供了技术支撑，有效的维护了整体业务的稳定性，实现对容器内的业务应用参数进行全面的收集、测量和存储，实现对集群内的业务应用情况进行监督。

附图说明

图1为本发明流程图；

图2为本发明方法应用的模型架构。

具体实施方式

附图仅用于示例性说明，不能理解为对本专利的限制；

为了更好说明本实施例，附图某些部件会有省略、放大或缩小，并不代表实际产品的尺寸；

对于本领域技术人员来说，附图中某些公知结构及其说明可能省略是可以理解的。

下面结合附图和实施例对本发明的技术方案做进一步的说明。

实施例1

如图1所示，一种基于Docker的业务应用可用度测量监控的实现方法，包括以下步骤：

S1：搭建Docker DM搭建；

S2：构建采集模块；

S3：构建测量模块；

S4：根据不同的策略对应用进行监控；

S5：监控客户端。

步骤S1的具体过程是：

1)、监控服务器：用于保存和汇总各宿主机的状态数据，同时也是提供Web图形化功能；

安装tomcat，用于提供web服务；

部署docker镜像仓库，用于提供局域网内的镜像仓库服务；

安装mysql数据库，用于数据的存储；

2)、宿主机：用于运行docker镜像的服务器，也是需要定时采集状态数据；

在监控的宿主机中通过yum命令安装docker，并修改docker的配置文件，添加局域网内的镜像仓库地址，以加快镜像的下载速度。

步骤S2的具体过程是：

1)、编写shell脚本：读取Linux下的/proc目录下的对应状态文件来获取当前宿主机的CPU、内存和网络状况，并将这些数据和当前主机标识组织成json格式发送给监控服务器；在脚本中为了使得数据能尽可能地反映当前状态，需要通过几次采集后取平均值以减低瞬时数据的对数据准确度的影响；

2)、编写shell脚本：调用docker的api获取当前主机中所有容器的运行状态数据并将这些数据和当前主机标识组织成json格式发送给监控服务器；

3)、通过crontab命令为宿主机添加定时任务，定时执行上面的两个脚本来获取监控的数据。为了使得数据具有一定的实时性，设置定时任务间隔为1分钟。

步骤S3的具体过程是：

1)、通过图形界面配置应用的依赖关系和应用的关联关系，应用的依赖关系即某个应用启动时，需要依赖其他应用，所以我们设置的是应用的启动顺序，在一整套的业务应用中会有多个应用，而当应用整体宕机，或者重启的时候，必须要有一定的执行顺序，这个就是应用的启动顺序和依赖关系；将该顺序进行记录并存储到数据库中；配置应用的关联关系，则是配置几个应用的关系,一套业务应用系统中往往都会有多个应用，而每个应用都是息息相关，所以要配置每一个应用和其他应用的关系，而配置的关系有必要关系和非必要关系，必须关系就是一个应用必须要在另外一个应用的基础运行的基础上才能启动，非必要关系就是指两个应用可以同级运行，没有另外一个应用，这个应用也可以单独启动；

2)、在描述完关系后，还需要对这些关系进行权值的设置，即当A应用完全依赖于B应用，当B应用不能使用，这时A应用也相应的完全不能使用，这时A依赖B的关系权值就为1；如果A不是完全不能使用，而是部分可以使用，这是可以根据影响的效果设置为小于1的权值，而这个权值将影响到后面监控过程中应用的可用度。

步骤S4的具体过程是：

1)、根据不同的策略对应用进行监控：监控可以分成应用监控管理和容器监控管理。应用监控可以监控当前应用的连接数和应用的流量，当连接数和流量超过设置的最大限制后，将推送客户发出警告，容器管理监控是监控当前运行中的应用容器所占的资源，如内存和cpu使用率，当内存和cpu超过设置的使用率时，将推送客户发出警告；

2)、通过宿主机的定时任务，定时采集相关的状态数据，定时发送给监控服务器：监控服务器再收到这些数据后，按照数据中的宿主机标识将这些数据汇总到一起；在收到数据后，先对数据按照宿主机标识进行分离，并保存到数据库中；同时根据这些状态数据更新宿主机的状态和Docker应用的状态，并且根据应用的依赖关系，按照当前最新的状态与权值，计算出当前应用的可用度，并将这个数据保存到数据库中。

步骤S5的具体过程是：

在监控客户端中，通过图形化的展示方式进行展示应用的拓扑关系、可用度和监控数据。

如图2所示，该基于Docker的业务应用可用度测量监控的实现方法是创建基于Docker的业务应用可用度监控模型，该监控模型包括监控客户端、可用度监控模块、测量模块、采集模块、Docker DM五个主要部分：

1)监控客户端负责监控数据的查询展示功能；

2)可用度监控模块用于业务应用可用度监控数据的处理过滤监控数据并进行存储；

3)测量模块负责对采集到的监控数据进行测算；

4)采集模块负责监控数据的采集预处理和监控数据的存储；

5)Docker DM用于提供业务应用的监控数据。

该方法是创建基于Docker的业务应用可用度测量监控模型，利用轻量级容器Docker的资源伸缩应用的能力完成业务应用可用度的测量监控，实现对容器内业务应用运行状态及参数进行全面的收集与存储，并提供对信息的测量分析和监控。

基于Docker的业务应用可用度测量监控模型中，利用Docker守护进程支持的RecGet API，实时监控一个运行容器中业务应用的资源利用情况、业务应用响应情况、业务性能数据情况，Docker默认返回JSON格式测量监控数据；根据返回的实时监控结果，参照业务可用度测量模型规则，对业务应用可用度进行测量分析，具体的实施方法如下：

1)定时调用RecGet API接口获得容器内业务应用参数的监控数据；

2)通过Docker返回容器监控数据；

3)通过采集模块对监控到的数据进行采集，进行数据预处理和过滤；

4)存储通过采集模块预处理并过滤的监控数据；

5)通过测量模块对采集模块传递的数据进行测算，返回测量数据调用结果；

6)获取测量数据进行业务可用度监控数据存储及统计；

7)存储可用度监控模块处理并过滤的监控数据；

8)查询存储的Docker容器的业务可用度监控信息；

9)获取所需的Docker容器的业务可用度监控信息；

10)返回所查询的监控信息；

11)应答查询的监控信息。

相同或相似的标号对应相同或相似的部件；

附图中描述位置关系的用于仅用于示例性说明，不能理解为对本专利的限制；

显然，本发明的上述实施例仅仅是为清楚地说明本发明所作的举例，而并非是对本发明的实施方式的限定。对于所属领域的普通技术人员来说，在上述说明的基础上还可以做出其它不同形式的变化或变动。这里无需也无法对所有的实施方式予以穷举。凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明权利要求的保护范围之内。

Claims (1)

1.一种基于Docker的业务应用可用度测量监控的实现方法，其特征在于，包括以下步骤：

S1：搭建Docker DM；

S2：构建采集模块；

S3：构建测量模块；

S4：根据不同的策略对应用进行监控；

S5：监控客户端；

所述步骤S1的具体过程是：

1)、监控服务器：用于保存和汇总各宿主机的状态数据，同时也是提供Web图形化功能；

安装tomcat，用于提供web服务；

部署docker镜像仓库，用于提供局域网内的镜像仓库服务；

安装mysql数据库，用于数据的存储；

2)、宿主机：用于运行docker镜像的服务器，也是需要定时采集状态数据；

在监控的宿主机中通过yum命令安装docker，并修改docker的配置文件，添加局域网内的镜像仓库地址，以加快镜像的下载速度；

所述步骤S2的具体过程是：

1)、编写shell脚本：读取Linux下的/proc目录下的对应状态文件来获取当前宿主机的CPU、内存和网络状况，并将这些数据和当前主机标识组织成json格式发送给监控服务器；在脚本中为了使得数据能尽可能地反映当前状态，需要通过几次采集后取平均值以减低瞬时数据的对数据准确度的影响；

2)、编写shell脚本：调用docker的api获取当前主机中所有容器的运行状态数据并将这些数据和当前主机标识组织成json格式发送给监控服务器；

3)、通过crontab命令为宿主机添加定时任务，定时执行上面的两个脚本来获取监控的数据，为了使得数据具有一定的实时性，设置定时任务间隔为1分钟；

所述步骤S3的具体过程是：

1)、通过图形界面配置应用的依赖关系和应用的关联关系，应用的依赖关系即某个应用启动时，需要依赖其他应用，所以我们设置的是应用的启动顺序，在一整套的业务应用中会有多个应用，而当应用整体宕机，或者重启的时候，必须要有一定的执行顺序，这个就是应用的启动顺序和依赖关系；将该顺序进行记录并存储到数据库中；配置应用的关联关系，则是配置几个应用的关系,一套业务应用系统中往往都会有多个应用，而每个应用都是息息相关，所以要配置每一个应用和其他应用的关系，而配置的关系有必要关系和非必要关系，必须关系就是一个应用必须要在另外一个应用的基础运行的基础上才能启动，非必要关系就是指两个应用可以同级运行，没有另外一个应用，这个应用也可以单独启动；

2)、在描述完关系后，还需要对这些关系进行权值的设置，即当A应用完全依赖于B应用，当B应用不能使用，这时A应用也相应的完全不能使用，这时A依赖B的关系权值就为1；如果A不是完全不能使用，而是部分可以使用，这是可以根据影响的效果设置为小于1的权值，而这个权值将影响到后面监控过程中应用的可用度；

所述步骤S4的具体过程是：

1)、根据不同的策略对应用进行监控：监控可以分成应用监控管理和容器监控管理，应用监控可以监控当前应用的连接数和应用的流量，当连接数和流量超过设置的最大限制后，将推送客户发出警告，容器管理监控是监控当前运行中的应用容器所占的资源，包括内存和cpu使用率，当内存和cpu超过设置的使用率时，将推送客户发出警告；

2)、通过宿主机的定时任务，定时采集相关的状态数据，定时发送给监控服务器：监控服务器再收到这些数据后，按照数据中的宿主机标识将这些数据汇总到一起；在收到数据后，先对数据按照宿主机标识进行分离，并保存到数据库中；同时根据这些状态数据更新宿主机的状态和Docker应用的状态，并且根据应用的依赖关系，按照当前最新的状态与权值，计算出当前应用的可用度，并将这个数据保存到数据库中；

所述步骤S5的具体过程是：

在监控客户端中，通过图形化的展示方式进行展示应用的拓扑关系、可用度和监控数据。

Images