一种边缘端服务告警的方法及装置

技术领域

本公开涉及物联网技术领域，尤其涉及一种边缘端服务告警的方法及装置。

背景技术

随着物联网的发展，基于云端的物联网解决方案渐渐无法满足人们日益增长的需求，越来越多的企业开始将目光转向边缘端服务，并将其作为云端服务延伸扩展，以加快数据分析的速度，便于企业更快更好的做出决策。边缘端服务如果出现故障，例如出现资源使用过载、业务逻辑报错等问题，不但会直接影响用户的正常使用，还会造成系统瘫痪、服务中断等问题。

发明内容

有鉴于此，本公开实施例提供了一种边缘端服务告警的方法及装置，以解决现有边缘端服务可靠性差，无法及时反馈设备状态，从而在设备出现紧急情况时无法及时进行告警，造成生产时间处理不及时的问题。

本公开实施例的第一方面，提供了一种边缘端服务告警的方法，包括：

指标采集模块根据采集的指标创建指标消息队列，并将指标消息队列传输至第一消息中间件，其中，指标至少包括系统磁盘使用率、系统CPU使用率、系统内存使用率；

当告警处理模块获取到第一消息中间件中的指标消息队列时，告警处理模块根据预设事件规则对指标消息队列进行处理，获得告警消息队列，并将告警消息队列传输至第二消息中间件；

当转发代理模块获取到告警消息队列时，将告警消息队列中的告警消息传输至云端服务模块；

云端服务模块对告警消息进行处理，以将告警消息发送至目标用户。

本公开实施例的第二方面，提供了一种边缘端服务告警的装置，包括：

指标采集模块，用于根据采集的指标创建指标消息队列，并将指标消息队列传输至第一消息中间件，其中，指标至少包括系统磁盘使用率、系统CPU使用率、系统内存使用率；

告警处理模块，用于当告警处理模块获取到第一消息中间件中的指标消息队列时，告警处理模块根据预设事件规则对指标消息队列进行处理，获得告警消息队列，并将告警消息队列传输至第二消息中间件；

转发代理模块，用于当获取到告警消息队列时，将告警消息队列中的告警消息传输至云端服务模块；

云端服务模块，用于对告警消息进行处理，以将告警消息发送至目标用户。

本公开实施例的第三方面，提供了一种计算机设备，包括存储器、处理器以及存储在存储器中并且可以在处理器上运行的计算机程序，该处理器执行计算机程序时实现上述方法的步骤。

本公开实施例的第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。

本公开实施例与现有技术相比存在的有益效果是：本公开实施例通过对边缘端服务实时运行指标进行采集，并经过告警处理模块选择符合事件告警规则的指标，将该指标传输至云端服务模块，云端服务模块对告警消息进行处理，以将告警消息发送至目标用户。本公开实施例通过云端服务模块的自动化告警使得用户能够对所需告警指标等进行实时监控，当出现告警消息时尽快通知目标用户，以便进行故障排除以及故障复盘，将事件影响及损失降至最低，及时排除隐患。

附图说明

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

图1是本公开实施例提供的一种边缘端服务告警的方法的流程图；

图2是本公开实施例提供的一种边缘端服务告警的方法中根据采集指标创建并传输指标消息队列的流程图；

图3是本公开实施例提供的一种边缘端服务告警的方法中对事件告警指标进行处理的流程图；

图4是本公开实施例提供的一种边缘端服务告警的方法中将消息传输至云端服务模块的流程图；

图5是本公开实施例提供的边缘端服务告警的方法中云端服务模块将告警消息发送至目标用户的流程图；

图6是本公开实施例提供的一种边缘端服务告警的方法中告警具体处理的流程图；

图7是本公开实施例提供的一种边缘端服务告警的装置的示意图；

图8是本公开实施例提供的计算机设备的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本公开实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本公开。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本公开的描述。

下面将结合附图详细说明根据本公开实施例的一种边缘端服务告警的方法及装置。

图1是本公开实施例提供的一种边缘端服务告警的方法的流程图。如图1所示，该边缘端服务告警的方法包括：

S11，指标采集模块根据采集的指标创建指标消息队列，并将指标消息队列传输至第一消息中间件，其中，指标至少包括系统磁盘使用率、系统CPU使用率、系统内存使用率。

示例性地，指标采集模块采集指标，并基于所采集的指标创建指标消息队列，再将指标消息队列传输至第一中间件，其中，指标包括：系统磁盘使用率、系统CPU(centralprocessing unit，中央处理器)使用率、内存使用率等。其中，消息中间件，是指RabbitMq，RabbitMq是实现高级消息队列协议的开源消息代理软件，也称面向消息的中间件，是应用层协议的一个开放标准。为面向消息的中间件设计，消息中间件主要用于组件之间的解耦，将消息保存至中间件，避免了消息在传输过程中的丢失。

本公开实施例之所以选择以消息队列进行传输，是因为消息队列的本身的特性决定的，它是在消息的传输过程中保存消息的容器，消息队列管理器在将消息传输至目标的过程中充当中间人的角色，消息队列的主要目的是提供路由并保证消息的传递，如果发送消息时接收者不能或暂时不能应用，消息队列则会保留消息，直到成功地传递它为止。

图2是本公开实施例提供的一种边缘端服务告警的方法中根据采集指标创建并传输指标消息队列的流程图。如图2所示，S11具体包括如下步骤：

S111，指标采集模块通过第三方类库采集系统磁盘使用率和系统CPU使用率。

第三方类库，是指系统之外的数据库，例如，Oshi。采用第三方类库采集系统磁盘使用率和系统CPU使用率，实现对终端系统的指标采集。其中，Oshi是Java的免费基于JNA(Java Native Access，Java语言)的本机操作系统和硬件信息库，提供一种跨平台的实现来检索系统信息。

S112，指标采集模块通过Linux命令获取系统内存使用率。

Linux命令是对Linux系统进行管理的命令，由于Oshi采集的内存使用率和实际Linux运行指标有偏差，因此，本公开实施例采用Linux命令采集内存使用率。本公开实施例指标采集模块选择通过Linux命令获取系统内存使用率，有效避免了上述偏差的出现。

S113，指标采集模块通过Docker(Docker stats，是一个开源的应用容器引擎)命令采集Docker部署的各模块的CPU使用率和内存使用率。指标采集模块通过Docker命令采集部署的各个模块的指标。其中，Docker让开发者可以打包应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何运行Linux或Windows机器上，也可以实现虚拟化。本公开实施例选择Docker是因为Docker完全使用沙箱机制，使得相互之间不会有任何接口，且Docker性能开销极低。

S114，基于采集的指标，创建指标消息队列，并将指标消息队列传输至第一消息中间件。

S12，当告警消息队列当告警处理模块获取到第一消息中间件中的指标消息队列时，告警处理模块根据预设事件规则对指标消息队列进行处理，获得告警消息队列，并将告警消息队列传输至第二消息中间件。

其中，预设事件规则至少包括以下一种：设备标识、规则标识、所属模块、指标标识、预算符、阈值、低阈值、高阈值、持续时间、事件等级、告警描述。

图3是本公开实施例提供的边缘端服务告警的方法中对事件告警指标进行处理的流程图。如图3所示，S12具体包括如下步骤：

S121，当告警处理模块订阅到指标消息队列时，告警处理模块根据预设事件规则对指标消息队列进行过滤，获取符合预设事件规则的告警消息，预设事件规则为元数据模块存储的事件规则。

示例性地，告警处理模块根据预设事件规则，将在系统磁盘使用率、系统CPU使用率、系统内存使用率中不符合告警事件规则与符合告警事件规则的事件告警指标分别进行相应处理，将不符合告警事件规则的事件告警指标过滤掉。

S122，根据告警消息创建告警消息列队，并将告警消息队列传输至第二消息中间件。

本公开实施例根据获取到的符合告警事件规则的事件告警指标，通过RabbitMq(实现高级消息队列协议的开源消息代理软件，亦称面向消息的中间件)创建告警消息队列，并将告警消息队列传输至第二消息中间件。

S13，当转发代理模块获取告警消息队列时，将告警消息队列中的告警消息传输至云端服务模块。

示例性地，将符合事件告警规则的事件告警指标经处理后进行上报。例如，将严重的事件告警、频繁发生的事件告警进行消息重组、分类，然后，将上述符合告警事件规则的事件告警指标，通过Mqtt(Message Queuing Telemetry Transport，遥信消息队列传输)协议进行上报。其中，目前高开销、高带宽占用的即时通讯协议已经渐渐不适应于物联网发展需要，Mqtt协议是一个基于客户端-服务器的消息发布/订阅传输协议，以极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务，作为一种低开销、低带宽占用的即时通讯协议，给物联网等传输带来广泛应用。因此，本公开实施例采用了Mqtt协议进行上报。

图4是本公开实施例提供的边缘端服务告警的方法中将告警消息队列传输至云端服务模块的流程图。如图4所示，S13具体包括如下步骤：

S131，转发代理模块获取到告警消息队列时，将告警消息队列中的告警消息通过Mqtt协议经由第一消息路由传输至Kafka消息总线。

其中，Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。Kafka是一个分布式的发布-订阅消息系统，能够支撑海量数据的数据传递。Kafka能够对消息创建备份保证了数据的安全。Kafka在保证了较高的处理速度的同时，又能保证数据处理的低延迟和数据的零丢失。因此，本公开实施例选择采用Kafka传递数据。

S132，转发代理模块将传输至Kafka消息总线的告警消息通过Http协议经由第二消息路由转发至云端服务模块。

Kafka消息总线获取到告警消息，通过Http(Hypertext Transfer Protocol，超文本传输协议)经由第二消息路由转发至云端服务模块。

S14，云端服务模块对告警消息进行处理，以将告警消息发送至目标用户。

具体应用场景下，云端服务模块获取到告警信息，将告警消息进行持久化处理后存入数据库，并将消息发送到智能平台消息群中，并告知目标用户。其中，智能平台可以是但不限于任何具有线上办公且通知功能的APP，例如钉钉。目标用户可以是项目负责人或相应运维人员。云端服务模块对告警消息进行持久化处理，以便当接收到用户进行历史记录查询的需求时，云端服务模块将提供相应查询的历史记录在浏览器上进行显示的服务。其中，持久化是将程序数据在持久状态和瞬时状态间转换的机制，即瞬时数据持久化为持久数据，例如，持久化至数据库中，能够长久地保存，以此，能够提供查询历史数据的服务。其中，用户查询的设备，这里不仅限于浏览器，还可以是其他任何具备查询功能的设备。

图5是本公开实施例提供的边缘端服务告警的方法中云端服务模块将告警消息发送至目标用户的流程图。如图5所示，S14具体包括如下步骤：

S141，云端服务模块通过智能平台消息API(Application ProgrammingInterface，应用程序接口)对告警消息处理，获得经过处理的告警消息，处理包括对告警消息设置信息级别，并将信息级别与不同颜色对应。

示例性地，把事件告警通过钉钉消息API处理，再将消息发送到钉钉消息群中，发送至项目负责人手机上，并同时@目标用户，使其及时查阅告警消息。其中，在钉钉服务处理消息时可设置消息级别：红色、橙色分别代表严重告警与次严重告警，绿色代表告警恢复正常。

S142，经过处理的告警消息发送至智能平台消息群中，并提醒目标用户。

图6是本公开实施例提供的一种边缘端服务告警的方法中告警具体处理的流程图。如图6所示，经过处理的告警消息发送至智能平台消息群中，并提醒目标用户步骤后，还包括：

S143，若告警消息持续存在，则按照预设频率发送告警消息至目标用户。

示例性地，告警云端服务模块调用钉钉API程序同时通知运维人员，显示红色或橙色，例如，预设采集周期是3分钟，当连续三次采集到同一台设备同一温度数据时，若3次温度都超过阈值，即出现3次告警消息时，才会发出告警。这是因为若采集的指标只有一次或两次超过阈值，有可能是程序启动等原因造成的，因此，不会进行告警。若连续出现3次采集的指标都超过阈值，则说明是非上述原因造成的，因此，才会采取告警措施。

当告警信息持续存在时，预设频率为1分钟，则每分钟发送告警消息至目标用户，发出告警的同时，在钉钉上调用API程序并@目标用户。例如，当预设频率为1分钟时，运维人员得知告警消息后及时进行处理，花了2分钟就完成处理，在这2分钟内，会出现两次“持续告警”的警报，且这2分钟内一直显示红色，由于距离下一次采集还剩1分钟，那么钉钉在这剩余1分钟内会显示绿色。

示例性地，若查询出存在持续的事件告警时，则按照预设频率发送告警消息至目标用户。其中，预设频率可以为每分钟、每两分钟、每30秒钟、每10秒、每秒等，根据需要可以进行灵活设定，这里不做具体限定。

S144，若未收到告警消息，则停止向目标用户发送告警消息，并发送告警恢复正常的提示消息至目标用户。

示例性地，由于告警颜色对应相应的告警级别，当收到橙色告警时，会对与该告警事件指标做相应地处理；当收到红色告警时，会对与该告警事件指标做相应地加急处理，并增派运维人员多维度补休或抢修；当经过相应处理之后，已不再显示告警状态时的红色或橙色，而是收到绿色告警时，则认为告警事件已经恢复正常，无需再进行处理。此时，目标用户会收到至少一条关于告警恢复正常的告知短信。

本公开实施例通过对边缘端服务实时运行指标进行采集，并经过告警处理模块选择符合事件告警规则的指标，将该指标传输至云端服务模块，云端服务模块对告警消息进行处理，以将告警消息发送至目标用户。通过云端服务模块的自动化告警使得用户能够对所需告警指标等进行实时监控，以便当出现告警消息时尽快通知目标用户，以便进行故障排除以及故障复盘，将事件影响及损失降至最低，及时排除隐患。

上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

下述为本公开装置实施例，可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节，请参照本公开方法实施例。

图7是本公开实施例提供的边缘端服务告警的装置的示意图。如图7所示，该边缘端服务告警的装置包括：

指标采集模块71，被配置为根据采集的指标创建指标消息队列，并将指标消息队列传输至第一消息中间件，其中，指标至少包括系统磁盘使用率、系统CPU使用率、系统内存使用率；

告警处理模块72，被配置为当获取到第一消息中间件中的指标消息队列时，根据预设事件规则对指标消息队列进行处理，获得告警消息队列，并将告警消息队列传输至第二消息中间件；

转发代理模块73，被配置为当获取到告警消息队列时，将告警消息队列中的告警消息传输至云端服务模块；

云端服务模块74，被配置为用于对告警消息进行处理，以将告警消息发送至目标用户。

边缘端服务告警的装置还包括：告警消息查询模块75，被配置为接收云端服务模块发送的告警消息，以及查询历史数据。告警消息查询模块75可以为客户端，通过查询事件告警历史记录，以便进行故障处理及故障复盘。

示例性地，用户通过浏览器或任何具备查询功能的设备等在云端服务模块查询事件告警历史记录，当云端提供与其查询相应的事件告警历史记录在浏览器上进行显示，如果得到告警消息，目标用户会对告警消息进行加急处理，及时止损。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本公开实施例的实施过程构成任何限定。

图8是本公开实施例提供的计算机设备8的示意图。如图8所示，该实施例的计算机设备8包括：处理器801、存储器802以及存储在该存储器802中并且可以在处理器801上运行的计算机程序803。处理器801执行计算机程序803时实现上述各个方法实施例中的步骤。或者，处理器801执行计算机程序803时实现上述各装置实施例中各模块/单元的功能。

示例性地，计算机程序803可以被分割成一个或多个模块/单元，一个或多个模块/单元被存储在存储器802中，并由处理器801执行，以完成本公开。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序803在计算机设备8中的执行过程。

计算机设备8可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算机设备。计算机设备8可以包括但不仅限于处理器801和存储器802。本领域技术人员可以理解，图8仅仅是计算机设备8的示例，并不构成对计算机设备8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如，计算机设备还可以包括输入输出设备、网络接入设备、总线等。

处理器801可以是中央处理单元(Central Processing Unit，CPU)，也可以是其它通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器802可以是计算机设备8的内部存储单元，例如，计算机设备8的硬盘或内存。存储器802也可以是计算机设备8的外部存储设备，例如，计算机设备8上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，存储器802还可以既包括计算机设备6的内部存储单元也包括外部存储设备。存储器802用于存储计算机程序以及计算机设备所需的其它程序和数据。存储器802还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。

在本公开所提供的实施例中，应该理解到，所揭露的装置/计算机设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/计算机设备实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本公开实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如，在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

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