CN115080338A

CN115080338A - 一种自动监测边缘设备容器内应用进程的系统及方法

Info

Publication number: CN115080338A
Application number: CN202210191743.6A
Authority: CN
Inventors: 任明; 邱连; 范律; 肖林松
Original assignee: Willfar Information Technology Co Ltd
Current assignee: Willfar Information Technology Co Ltd
Priority date: 2022-02-28
Filing date: 2022-02-28
Publication date: 2022-09-20

Abstract

本发明适用于电力物联网技术领域，涉及一种自动监测边缘设备容器内应用进程的系统，包括：Web管理模块，用于自动构建镜像包，通过在边缘设备部署容器，发布监控配置信息，获取边缘设备报警信息；Edge Daemon部署模块，用于接收Web管理模块的命令，调用容器的Api接口；Appctl模块，实现CLI命令供Edge Daemon部署模块调用，用于启动监控进程模块；监控进程模块，用于获取容器内各个应用进程的资源使用情况并对各个应用进程的阈值超出设定值进行自动报警，同时监测应用进程的状态，当监测到应用进程异常退出时，对其进行重启处理。本发明能够自动对容器中的多个应用进程的资源使用情况进行监测，当应用进程异常时能够及时对其进行处理。

Description

一种自动监测边缘设备容器内应用进程的系统及方法

技术领域

本发明属于电力物联网技术领域，尤其涉及一种自动监测边缘设备容器内应用进程的系统及方法。

背景技术

随着物联网的发展，物联网终端设备数量也随之快速增加，由于高昂的传输成本、较高的响应时延以及网络带宽有限，网络边缘设备所产生的海量数据已经不适用于传统基于云服务的集中式数据处理方式。随着以Docker(一个开源的应用容器引擎)为代表的虚拟化容器技术的快速普及和使用，能够在资源受到隔离的进程中运行应用程序及其依赖关系，也可以轻松打包应用程序的代码、配置和依赖关系，将其编程容易使用的构建块，从而实现环境一致性、运营效率、开发人员生产力和版本控制等诸多目标。容器可帮助保证应用程序快速、可靠、一致性部署，其间不受部署环境的影响，容器还赋予我们对资源更多的精细化控制能力，让我们的设备资源效率更高。

Docker容器技术普及之后，有些应用为了要求更好的独立性和隔离性往往将不用的应用运行在不同的容器中，当大量的物连接到网络上后，应对爆炸式的应用业务需求及需求变化，应用越来越多，意味着容器也越来越多，容易造成资源浪费。随着电力物联网所要求实现状态全面感知、信息快速高效处理、应用便捷灵活部署更新等需求的增强，越来越多的业务应用APP化，边缘设备资源有限，一个业务应用置于一个容器已经不能满足需求，因此有必要对应用 APP进行归类，对于有些关联性较大的应用APP，使其在同一容器中运行。

当容器中运行的应用APP越来越多时，就会存在资源竞争，当某个应用APP 运行出现异常占用大量资源(包括内存、CPU、磁盘)直至将资源耗尽时，会导致运行该应用APP的容器异常，进而容器内的其他应用APP也会出现异常，最终容器以及容器内的应用APP都会受到影响。同样容器中的某个应用APP进程不在线或者终止运行时，需要及时拉起，以免业务受到严重影响。

因此自动监测容器内应用APP进程的状态，以及自动掌握容器内资源使用情况，对容器内应用APP进程的资源进行有效阈值限定，有助于最大程度发挥容器的性能，提高应用APP进程的吞吐率，避免内存或CPU溢出错误，成为需要解决的至关重要的问题。但现有的技术方案只能做到容器级别的管理无法做到容器内边缘应用的管理，大多只是监控容器，并不监控容器内的应用APP，因此，如何提供一种能够自动监测边缘设备容器内应用进程的系统是本技术领域人员亟待解决的问题。

发明内容

针对现有技术的不足，本发明的目的是提供一种自动监测边缘设备容器内应用进程的系统，以解决现有技术中只能监测容器而无法监测容器内应用进程的问题；此外，本发明还提供了一种自动监测边缘设备容器内应用进程的方法。

为了解决上述技术问题，本发明采用了如下的技术方案：

第一方面，本发明提供了一种自动监测边缘设备容器内应用进程的系统，包括：

Web管理模块，用于自动构建镜像包，通过在边缘设备部署容器，发布监控配置信息，获取边缘设备报警信息；

Edge Daemon部署模块，用于接收所述Web管理模块的命令，调用容器的 Api接口，用于容器的部署、启动、更新和停止；

Appctl模块，实现CLI命令供所述Edge Daemon部署模块调用，用于启动监控进程模块，实现应用APP的启动、停止、安装、卸载、更新APP告警阈值和APP告警信息查询；

监控进程模块，用于获取容器内各个应用进程的资源使用情况并对各个应用进程的阈值超出设定值进行自动报警，当应用进程的资源占用恢复到正常时取消报警，同时监测应用进程的状态，当监测到应用进程异常退出时，对其进行重启处理。

进一步的，还包括消息中间件MQTT Broker，用于所述Web管理模块与所述EdgeDaemon部署模块之间的通讯。

进一步的，所述消息中间件MQTT Broker的消息队列采用MQTT 3.1.1协议，使用的消息队列中间件为Mosquitto。

进一步的，还包括Unix Socket模块，用于容器内各个应用进程之间的通信。

第二方面，本发明还提供了一种自动监测边缘设备容器内应用进程的方法，包括以下步骤：

S10、将监控应用进程的可执行文件打包到基础镜像内；

S20、创建并配置基础镜像的Dockerfile文件，将监控进程模块的启动命令加入Docker的CMD指令；

S30、Edge Daemon部署模块通过接收Web管理模块命令部署并启动应用程序的容器，容器启动后自动启动所述监控进程模块；

S40、所述监控进程模块获取容器内所有的应用进程信息；

S50、所述监控进程模块为容器内每个应用进程的分别设置标志位；

S60、所述监控进程模块获取各个应用进程的资源使用情况并判断是否超过标志位；

S70、所述监控进程模块对超出标志位的应用进程进行自动报警；所述监控进程模块同时监测应用进程的状态，当监测到应用进程异常退出时，对其进行重启处理。

进一步的，所述步骤S50中标志位包括进程异常标志位、CPU超出阈值标志位、内存超出阈值标志位和磁盘超出阈值标志位。

进一步的，所述步骤S70中，当应用进程连续三次超过所述进程异常标志位时，重启该应用进程。

进一步的，所述步骤S60中各个应用进程的资源使用情况包括当前CPU使用情况、当前内存使用情况和当前磁盘使用情况。

进一步的，所述步骤S40中的应用进程信息包括应用进程名称和PID号。

本发明提供的自动监测边缘设备容器内应用进程的系统及方法与现有技术相比，至少具有如下有益效果：

本发明能够自动对容器中的多个应用进程的资源使用情况进行监测，还能通过设定的标志位对应用进程的CPU、内存、磁盘使用情况进行告警上报，并在应用进程异常退出时重启该应用进程，当应用进程异常时能够及时对其进行处理，防止其长时间异常导致业务受到影响。

附图说明

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

图1为本发明实施例提供的一种自动监测边缘设备容器内应用进程的系统整体框架图；

图2为本发明实施例提供的一种自动监测边缘设备容器内应用进程的方法中镜像构建流程图；

图3为本发明实施例提供的一种自动监测边缘设备容器内应用进程的方法中容器部署流程图；

图4为本发明实施例提供的一种自动监测边缘设备容器内应用进程的系统的Edge Daemon部署模块的结构图；

图5为本发明实施例提供的一种自动监测边缘设备容器内应用进程的系统的模块通讯机制流程图；

图6为本发明实施例提供的一种自动监测边缘设备容器内应用进程的系统的量测数据/事件数据、请求数据和响应数据的属性填写说明图；

图7为本发明实施例提供的一种自动监测边缘设备容器内应用进程的方法流程图。

具体实施方式

除非另有定义，本文所使用的所有技术和科学术语与属于本发明技术领域的技术人员通常理解的含义相同；本文在说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本发明，例如，术语“长度”、“宽度”、“上”、 “下”、“左”、“右”、“前”、“后”、“竖直”、“水平”、“顶”、“底”、“内”、“外”等指示的方位或位置为基于附图所示的方位或位置，仅是便于描述，不能理解为对本技术方案的限制。

本发明的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含；本发明的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。本发明的说明书和权利要求书及上述附图说明中，当元件被称为“固定于”或“安装于”或“设置于”或“连接于”另一个元件上，它可以是直接或间接位于该另一个元件上。例如，当一个元件被称为“连接于”另一个元件上，它可以是直接或间接连接到该另一个元件上。

此外，在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本发明的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

本发明提供了一种自动监测边缘设备容器内应用进程的系统，用于监测容器内应用进程的状态，自动监测边缘设备容器内应用进程的系统包括：Web管理模块，用于自动构建镜像包，通过在边缘设备部署容器，发布监控配置信息，获取边缘设备报警信息；EdgeDaemon部署模块，用于接收所述Web管理模块的命令，调用容器的Api接口，用于容器的部署、启动、更新和停止；Appctl 模块，实现CLI命令供所述Edge Daemon部署模块调用，用于启动监控进程模块，实现应用APP的启动、停止、安装、卸载、更新APP告警阈值和APP告警信息查询；监控进程模块，用于获取容器内各个应用进程的资源使用情况并对各个应用进程的阈值超出设定值进行自动报警，当应用进程的资源占用恢复到正常时取消报警，同时监测应用进程的状态，当监测到应用进程异常退出时，对其进行重启处理。

本发明能够自动对容器中的多个应用进程的资源使用情况进行监测，当应用进程异常时能够及时对其进行处理。

为了使本技术领域的人员更好地理解本发明方案，下面将结合附图，对本发明实施例中的技术方案进行清楚、完整地描述。

本发明提供了一种自动监测边缘设备容器内应用进程的系统，用于监测容器内应用进程的状态，如图1所示，所述自动监测边缘设备容器内应用进程的系统包括：Web管理模块，用于自动构建镜像包，通过发布平台在边缘设备部署容器，发布监控配置信息，获取边缘设备报警信息；Edge Daemon部署模块，通过监听以及订阅MQTT Broker消息接收Web管理模块的命令，调用Docker 的Api接口，用于容器的部署、启动、更新、停止等，调用Appctl模块用于应用进程的启动、停止、安装、卸载、更新APP告警阈值、APP告警信息查询等，其中消息中间件MQTT Broker用于Web管理模块与Edge Daemon部署模块之间的通讯，消息队列采用MQTT 3.1.1协议，使用的消息队列中间件为Mosquitto； Appctl模块，实现CLI命令供Edge Daemon部署模块调用，用于启动监控进程模块，实现应用APP的启动、停止、安装、卸载、更新APP告警阈值、APP告警信息查询等；监控进程模块，用于获取容器内各个应用进程的资源使用情况并对各个应用进程的阈值超出设定值进行自动报警，当应用进程的资源占用恢复到正常时取消报警，同时监测应用进程的状态，当监测到应用进程异常退出时，对其进行重启处理，当应用进程不在位时，将其重新拉起；Unix Socket模块，用于容器内各个应用进程之间的通信。

具体地，本实施例中，通过Web管理模块，配置应用告警阈值，自动构建应用镜像包，在边缘设备部署容器，发布告警信息。整体操作流程如下：

a.配置应用告警阈值(包括内存、CPU、磁盘)以及资源限制，保存在应用包文件；

应用包文件结构如下：

app01

--app.cfg

--bin

--app01

--lib

--libsg.so

--version.cfg

其中app.cfg文件为json结构，描述app的如下信息：

{

"appname":"example_app",//app名称

"binname":"bin/example_app",//执行文件名

"libpath":"lib",//依赖库文件夹

"CpuLimit":4,//cpu最大使用数(个)

"MemoryLimit":256,//内存最大使用限制(M)

"DiskLimit":90,//磁盘最大使用限制(M)

"CpuThreshold":90,//cpu告警阀值

"MemoryThreshold":90,//内存告警阀值

"DiskThreshold":90,//磁盘告警阀值

}

其中bin文件夹为存储APP的程序文件；lib文件夹为存储APP的依赖库文件；version.cfg为应用版本声明文件。

b.创建并配置Dockerfile文件，将监控程序的启动命令(CLI命令)加入 Docker的CMD指令，保证了容器启动时自动启动监控进程；

Dockerfile文件：

FROM 192.168.233.200:9000/edge/alpine-armv7-cplus:1.0

ADD appctl/usr/local/bin

ADD version/usr/local/bin

CMD["appctl","daemon"]

c.自动构建应用镜像包

结合图2，获取应用程序包文件，创建Dockerfile文件，生成Docker Build 命令，并在Docker环境下执行，将生成的镜像推送到执行的harbor镜像仓库，如果构建过程过慢，则采用异步处理，收到构建命令后立即返回“处理中”，然后再轮询构建进度，错误时返回对应的错误信息。

d.容器部署流程

结合图3，Web管理模块会对应用包、镜像包进行管理，并配置它们之前的关系，将应用包构建成镜像放入容器镜像仓库，将构建好的容器镜像注册为边缘应用，将配置好的边缘应用清单下发至边缘端Edge Daemon部署模块，Edge Daemon部署模块依据配置进行部署和更新，同时对边缘设备中容器中的应用进行监控，并接收来自边缘设备的告警信息，例如内存、CPU、磁盘等告警。

具体地，本实施例中，Edge Daemon部署模块主要通过MQTT协议与Web 管理模块进行交互，接收平台指令，同时通过调用Docker API与Docker Engine 进行通讯，实现对容器的管理，包括容器部署、启动、停止、卸载等，镜像的拉取及删除等。主要流程如下：

a.用户在Web页面上发起部署更新流程，预先配置好边缘设备需要运行的容器清单、部署方式及运行参数等；

b.Web管理模块将操作请求(部署、启动、停止、卸载等)发布到MQTT Broker (请求中不包括容器文件流，仅包含文件的下载路径)，下载路径中带授权码，一小时后自动过期；

c.Edge Daemon部署模块订阅MQTT Broker相关操作请求(部署、启动、停止、卸载等)，根据容器的下载路径，从文件服务(镜像仓库)中采用Http(s)协议将文件(包括镜像包及挂载文件)下载到本地，并对镜像包进行签名验证，验证通过则继续更新流程，否则返回错误；

在访问Http私有镜像仓库时，需在/etc/docker目录下添加daemon.json文件，并加入{“insecure-registries”:[“registeryIp:port”]}，修改后需重启Docker；

d.Edge Daemon部署模块依据请求中的应用清单、容器运行参数来调用 DockerAPI对容器进行部署操作，过程中会异步上报部署/更新进度及结果信息，返回到Web管理模块；

e.Edge Daemon部署模块封装了Docker API实现对容器的管理，主要包括镜像的拉取及删除、实现对容器的创建、删除、启动、停止等，支持获取容器的CPU，内存，磁盘IO及网络IO使用情况，同时也提供状态查询接口供其他模块调用。

结合图4，Edge Daemon部署模块内部结构如下：

使用Golang作为开发语言，外部模块采用MQTT Broker，内部模块间通讯采用beehive架构，此模块不会调用其他模块的方法，保证其独立性，便于以后对容器技术的替换而不用修改其他模块，DaemonModule按MQTT以及beehive 的格式定义，并扩展两个属性：Edge Daemon部署模块负责容器中应用的部署、启停、删除等，MessageHandler负责与MQTTBroker交互处理Web管理模块请求，以及处理其他模块对本模块的beehive请求，DokcerOperator封装了对 Docker容器及镜像等的基本操作，负责Docker的各种操作(镜像的拉取及删除、实现对容器的创建、删除、启动、停止等)。

具体地，本实施例中，MQTT Broker采用的消息中间件是Mosquitto，主要包括MQTT通讯机制，Topic编码规范，消息结构，具体如下：

MQTT通讯机制：

如图5所示，每个模块有一个唯一编码(EdgeNodeCode/ServiceCode)，每个模块监听3个消息队列(类似邮箱)，分别对应3个通配Topic，按数据类型分为：接收量测数据/事件数据的队列、接收请求数据的队列和接收响应数据的队列 (Auto-Delete,组件停止时自动删除)，拆分成3个队列的目的是防止大量的流数据堵塞请求/响应数据。发布者发布消息时通过Topic指定要发送给哪个组件的哪个队列。

Topic编码规范：

Topic规范：{发送节点编号}/{发送组件编号}/{消息类型}/{接收节点编号}/{接收组件编号}/{动态多层路径}

发送节点编号：发出消息的边缘节点唯一编号。

发送组件编号：发出消息的模块唯一编号。

消息类型：消息类型包括3类：req(请求),res(响应),data(量测数据或事件数据)。

接收节点编号：接收消息的边缘节点唯一编号，当消息类型为data时，可不指定接收节点，用*代替。

接收组件编号：接收消息的模块唯一编号，当消息类型为data时，可不指定接收组件，用*代替。

动态多层路径：当消息类型为req时，动态路径主要表示请求响应的路径，可多层。如下：

eg:node1/app1/req/node2/app2/container/deploy

当消息类型为res时，需指定组件实例的唯一编号(解决组件多实例部署时的响应消息接收方)。如下：

eg:node2/app2/res/node1/app1/app1_guid/container/deploy

当消息类型为data时，动态路径主要表示数据的类型。如下：

eg:node1/app1/data/*/*/alarminfo

消息结构：

a.消息结构说明

{

SendTime:time.Time //发送时间

UniqueID:string //数据唯一ID

CorrelationID:string //响应ID，与请求ID对应(UniqueID)

ReplyTo:string //指明响应消息需要发送到哪个topic

Auth:string //加密认证方式，为空时未做安全认证

UserProperties:interface{} //用户自定义属性{key:value,key:value}

MessageBody:[]byte //业务消息体,支持签名认证

}

如果Auth有值，则需要线依据其值对MessageBody做解密/认证处理，MessageBody未签名加密时为json字节流。

如图6所示为量测数据/事件数据、请求数据和响应数据的属性填写说明。

b.MessageBody数据结构-量测数据

MessageBody内容:

{

ec:string //子设备or边缘节点编号

lb: //给消息打的label标签-可选

{

“key”:string //“value扩展属性值”

}

msg:[

{

id:string //标签名称

t:int64 //采集时间-微秒

q:int //数据质量

v:interface{}//采集值(字符串/数字类型/数组)

}

]

}

说明：

ec:子设备or边缘节点编号(Endpoint Code)

lb:给消息打的标签信息-可选，key-value键值对，value只支持字符串 msg:采集的消息数组

id:标签名称(消息类型),string

t:采集时间-微秒,int64

q:数据质量

v:采集值(字符串/数字类型/数组)

v为数组类型时，结构如下：

[

[“采集值”,“偏移时长-微秒”,“质量”],

[“采集值”,“偏移时长-微秒”,“质量”]

]

采集值：只能为字符串或数字，不支持数组。

偏移时长：相对于t的偏移时长，微秒。

c.MessageBody数据结构-事件数据&请求响应

对于事件数据格式无要求，对于请求响应数据格式无要求。

具体地，本实施例中，通过Appctl模块实现CLI命令包括启动监控进程，应用进程的安装、启动、停止、更新，更新告警阀值，告警信息查询等，其中启动监控进程命令配置在Dockerfile文件中。主要流程如下：

将Appctl模块打包编译成可执行文件Appctl；

在打包应用容器镜像的Dockerfile文件中添加ADD命令，将可执行文件 Appctl放置在/usr/local/bin目录里；

在打包应用容器镜像的Dockerfile文件中添加启动监控进程的CMD命令，这样每个应用容器创建并运行时，就会自动启动监控进程；

Appctl模块包含两部分，一部分是容器内应用进程相关的命令(应用进程的安装、卸载、启动、重启等命令)，一部分是容器内应用进程的守护以及监控进程。

Appctl模块的CLI命令通过go语言实现，主要命令如下：

监控进程启动命令：appctl daemon

应用APP安装命令：appctl install--app＝app-name

应用APP卸载命令：appctl uninstall--app＝app-name

应用APP启动命令：appctl start--app＝app-name

应用APP重新启动命令：appctl restart--app＝app-name

应用APP停止命令：appctl start--app＝app-name

应用APP告警阀值信息查询命令：appctl info--app＝app-name

应用APP告警阀值设置命令：appctl set--app＝app-name--cpu＝thresh --mem＝thresh--disk＝thresh

应用APP配置信息查询命令：appctl querycfg--app＝app-name

应用APP重新加载配置命令：appctl reload--app＝app-name

应用APP告警信息查询命令：appctl queryevent--app＝app-name

具体地，本实施例中，Unix Socket模块，用于容器内进程间的通讯，当容器内某个进程APP的阈值发生变化，需要及时通知监控进程模块，此通信方式与普通的网络socket相比，不需要进行复杂的数据打包拆包、校验和计算验证，不需要走网络协议栈，安全可靠，服务端与客户端不需要IP和端口，只需要文件路径。

具体地，服务端：

创建socket并绑定地址为/var/run/appctl-daemon.sock；

这个地址是一个.sock文件的地址，设定地址和sock文件名后，服务端启动成功后会在对应目录生成该sock文件，由于已经存在该文件，服务会启动失败，因此在每次启动前都应该先移出该文件。

开始监听客户端；

接收客户端的连接请求；

进行数据传输；

通信完成后关闭socket；

客户端：

创建并绑定与服务端的地址，此地址与服务端一样；

创建并绑定客户端地址为/var/run/appctl-cli.sock；

与服务端建立连接；

发送数据请求；

通信完成后关闭socket。

具体地，本实施例中，监控进程模块通过创建启动容器时自动启动，负责监控容器内的应用状态，主要功能包括APP运行状态，监控CPU、内存、磁盘的使用情况，通过设定的阈值，来对容器内应用的CPU，内存，磁盘等进行告警上当恢复正常后，上报告警解除事件。整体流程如下：

从配置文件获取容器内所有的应用进程名；

进行for循环，依次遍历所有进程；

根据进程名获取应用进程信息，例如PID号等；

为每个应用进程分别设置进程异常标志位、CPU超出阈值标志位、内存超出阈值标志位、磁盘超出阈值标志位；

检查进程是否在线，如果不在线，则上报告警，同时进程异常标志位是否置1(连续三次检查不在线则置1)，如果标志位置1，则重新拉起该进程；

获取应用进程的当前内存使用情况，并计算进程内存使用率是否超过阈值，计算公式为：

Threold＝当前内存使用(UsedMemory)/内存最大使用限制(MemoryLimit) 百分比

将Threold与内存阈值(MemoryThreshold)进行比较，当Threold超过内存阈值时，则告警上报，当Threold低于内存阈值时，则取消报警；同时进程内存阈值标准位是否置1(连续3次检查不在线则置1)，如果标志位置1，则重启该应用进程。

获取应用进程的当前CPU使用情况，并计算进程CPU使用率是否超过阈值，计算公式为：

Threold＝当前CPU使用(UsedCpu)/Cpu最大使用限制(CpuLimit)百分比

将Threold与CPU阈值(CpuThreshold)进行比较，当Threold超过CPU 阈值时，则告警上报，当Threold低于CPU阈值时，则取消报警；同时进程CPU 阈值标准位是否置1(连续3次检查不在线则置1)，如果标志位置1，则重启该应用进程。

获取应用进程的当前磁盘使用情况，并计算进程磁盘使用率是否超过阈值，计算公式为：

Threold＝当前磁盘使用(UsedDisk)/内存最大使用限制(DiskLimit)百分比

将Threold与磁盘阈值(DiskThreshold)进行比较，当Threold超过磁盘阈值时，则告警上报，当Threold低于磁盘阈值时，则取消报警；同时进程磁盘阈值标志位是否置1(连续3次检查不在线则置1)，如果标志位置1，则重启该进程。

上述实施例中所述的自动监测边缘设备容器内应用进程的系统，结构简单，通过Web管理模块配置应用告警阈值，构造Dockerfile文件，自动打包构建应用镜像包，通过MQTT协议与Edge Daemon部署模块进行交互，Edge Daemon 部署模块接受到平台的命令后，开始创建启动容器，进而启动监控进程模块，监控进程模块自动监测容器内所有应用进程的运行状态，当应用进程异常时能够及时对其进行重启处理或拉起，防止其长时间异常导致业务受到影响，为容器内分布式任务的资源优化、及时发现内存或者CPU潜在威胁提供有效依据，进而达到资源的有效利用，提高边缘设备整体系统性能的目的。

本发明实施例还提供了一种自动监测边缘设备容器内应用进程的方法，如图7所示，包括以下步骤：

S10、将监控应用进程的可执行文件打包到基础镜像内；

S30、Edge Daemon部署模块通过接收Web管理模块命令部署并启动应用程序的容器，容器启动后自动启动监控进程模块；

S40、监控进程模块获取容器内所有的应用进程信息；

应用进程信息包括应用进程名称和PID号；

S50、监控进程模块为容器内每个应用进程的分别设置标志位；

标志位包括进程异常标志位、CPU超出阈值标志位、内存超出阈值标志位和磁盘超出阈值标志位；

S60、监控进程模块获取各个应用进程的资源使用情况并判断是否超过标志位；

各个应用进程的资源使用情况包括当前CPU使用情况、当前内存使用情况和当前磁盘使用情况；

S70、监控进程模块对超出标志位的应用进程进行自动报警；监控进程模块同时监测应用进程的状态，当应用进程连续三次超过进程异常标志位时，对其进行重启处理。

上述实施例所述的一种自动监测边缘设备容器内应用进程的方法，过程简单，用于容器中各应用进程的资源使用情况以及状态监测，及时发现应用进程在使用资源方面潜在的威胁，防止进程突发异常导致业务受损，同时达到资源优化使用，进而提高容器或者集群系统的性能的目的。

显然，以上所描述的实施例仅仅是本发明较佳实施例，而不是全部的实施例，附图中给出了本发明的较佳实施例，但并不限制本发明的专利范围。本发明可以以许多不同的形式来实现，相反地，提供这些实施例的目的是使对本发明的公开内容的理解更加透彻全面。尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来而言，其依然可以对前述各具体实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等效替换。凡是利用本发明说明书及附图内容所做的等效结构，直接或间接运用在其他相关的技术领域，均同理在本发明专利保护范围之内。

Claims

1.一种自动监测边缘设备容器内应用进程的系统，其特征在于，包括：

Edge Daemon部署模块，用于接收所述Web管理模块的命令，调用容器的Api接口，用于容器的部署、启动、更新和停止；

2.根据权利要求1所述的一种自动监测边缘设备容器内应用进程的系统，其特征在于，还包括消息中间件MQTT Broker，用于所述Web管理模块与所述Edge Daemon部署模块之间的通讯。

3.根据权利要求2所述的一种自动监测边缘设备容器内应用进程的系统，其特征在于，所述消息中间件MQTT Broker的消息队列采用MQTT 3.1.1协议，使用的消息队列中间件为Mosquitto。

4.根据权利要求3所述的一种自动监测边缘设备容器内应用进程的系统，其特征在于，还包括Unix Socket模块，用于容器内各个应用进程之间的通信。

5.一种自动监测边缘设备容器内应用进程的方法，其特征在于，包括以下步骤：

S10、将监控应用进程的可执行文件打包到基础镜像内；

S40、所述监控进程模块获取容器内所有的应用进程信息；

6.根据权利要求5所述的一种自动监测边缘设备容器内应用进程的方法，所述步骤S50中标志位包括进程异常标志位、CPU超出阈值标志位、内存超出阈值标志位和磁盘超出阈值标志位。

7.根据权利要求6所述的一种自动监测边缘设备容器内应用进程的方法，其特征在于，所述步骤S70中，当应用进程连续三次超过所述进程异常标志位时，重启该应用进程。

8.根据权利要求5所述的一种自动监测边缘设备容器内应用进程的方法，其特征在于，所述步骤S60中各个应用进程的资源使用情况包括当前CPU使用情况、当前内存使用情况和当前磁盘使用情况。

9.根据权利要求5所述的一种自动监测边缘设备容器内应用进程的方法，其特征在于，所述步骤S40中的应用进程信息包括应用进程名称和PID号。