CN115208930B - 一种基于Kappa架构的监控系统及监控方法 - Google Patents

Abstract

本发明提供了一种基于Kappa架构的监控系统及监控方法，包括下层子系统、中层子系统和上层子系统；下层子系统由数据采集器、数据通信器和线程控制器构成，涉及到的内容包括Zookeeper监听业务、Netty客户端业务以及Future异步回调技术；中层子系统由数据接收器和数据分类器构成，涉及到的内容包括Netty服务端业务、Zookeeper分布式协调服务和Kafka消息引擎；上层子系统由监控终端和数据传感器构成，涉及到的技术包括SpringBoot服务端、Flink流处理技术。应用本技术方案可实现缓解基于UDP协议开发的监控系统，所产生的丢包问题，以及基于HTTP协议开发的监控系统，所产生的传输数据包冗余问题，同时还能够发挥Kappa架构的优势。

Description

一种基于Kappa架构的监控系统及监控方法

技术领域

本发明涉及服务器监控系统技术领域，特别是一种基于Kappa架构的监控系统及监控方法。

背景技术

Kappa架构是软件工程体系架构中的一种实时分析流处理架构，其核心部分主要有两个要点：流计算引擎以及消息引擎。Kappa架构与Lambda架构相比，架构简单，以流数据为中心，并且开发工作量较少，不需要额外的开发、维护庞大ETL系统以及各类中间报表批处理业务系统。但Kappa架构设计的系统也具有一定的缺陷，即功能性不如Lambda架构全面，更适合处理以时间作为重要指标的各类数据源。

在Kappa架构的流处理计算业务中，我们一般会考虑三种时间指标，分别为事件时间、进入时间以及处理时间。其中事件时间是指某事件发生的具体时间，进入时间是指事件记录流向消息引擎的具体时间，最后，处理时间是指事件记录正式被流计算架构处理的具体时间。监控系统的大部分业务都与事件时间相关，大量的时序数据都可以作为业务处理重要指标，故可以将Kappa架构作为监控系统的体系设计架构。

目前市面上监控系统所使用的传输层协议主要包括TCP协议、UDP协议、HTTP协议，但是3种协议方法，但除开TCP协议，UDP协议和HTTP协议在作为监控系统的传输层协议使用时，都具有一定的缺陷：UDP协议是一种无连接的、不可靠的传输层协议，其特点是在网络环境较差，负载过大的情况下，不能够保证告警消息能够在规定的时间内到达目标主机；HTTP协议在每个数据包都包含了相关的HTTP头信息。这些头信息在监控流数据传输业务中往往都是冗余的，无用的。

发明内容

有鉴于此，本发明的目的在于提供一种基于Kappa架构的监控系统及监控方法，实现缓解基于UDP协议开发的监控系统，所产生的丢包问题，以及基于HTTP协议开发的监控系统，所产生的传输数据包冗余问题，同时还能够发挥Kappa架构的优势。

为实现上述目的，本发明采用如下技术方案：一种基于Kappa架构的监控系统，包括下层子系统、中层子系统和上层子系统；下层子系统由数据采集器、数据通信器和线程控制器构成，涉及到的内容包括Zookeeper监听业务、Netty客户端业务以及Future异步回调技术；中层子系统由数据接收器和数据分类器构成，涉及到的内容包括Netty服务端业务、Zookeeper分布式协调服务和Kafka消息引擎；上层子系统由监控终端和数据传感器构成，涉及到的技术包括SpringBoot服务端、Flink流处理技术。

在一较佳的实施例中，所述数据采集器包括配置文件IO模块、日志文件读取模块及本地数据管程模块；

所述数据通信器包括Netty客户端模块、日志文件版本缓存模块及Zookeeper结点树模块；

所述线程控制器包括线程分发模块、线程控制模块、脚本驱动模块及线程状态回滚模块。

在一较佳的实施例中，所述数据接收器包括Netty服务端模块及数据预处理模块；

所述数据分类器包括数据分类模块及Kafka发布端模块。

在一较佳的实施例中，所述数据传感器包括流量计算结点、集群性能计算结点、指标基线告警计算结点以及各个具体业务分析结点；

所述监控终端包括Kafka消息订阅端模块、视图层接口模块、集群服务调度模块、资源信息管理模块及监控终端Zookeeper结点树模块。

本发明还提供了一种基于Kappa架构的监控方法，包括以下步骤：

步骤1：监控数据收集，部署在被监控结点的下层子系统会定时收集本服务器的OS监控数据，应用程序日志数据以及业务逻辑日志数据，并将这些数据以JSON的数据格式通过Netty客户端发送至位于事件路由服务器的中层子系统；与此同时，直接来自业务客户端的本地业务数据也通过Cookie被传输至中层子系统；

步骤2：监控数据预处理，中层子系统将收集到的各类监控流数据以及直接来自用户客户端的数据，通过数据预处理模块，根据策略，补正缺失数据并且过滤的无用数据，同时将经过处理的流数据汇集到本机的数据分类器模块当中；

步骤3：监控数据分类，数据分类器根据数据处理的结果和源数据JSON标记的种类，按照不同的类别、紧急程度以及具体的功能需求，分发到不同的Kafka主题当中；

步骤4：监控数据处理，使用基于yarn管理的Flink集群从Kakfa拉取数据，并对各类数据进行实时分析，生成视图信息，同时根据提前设计好的指标基线，生成通知信息，将不同的处理结果分发到不同的Kafka主题；

步骤5：视图层数据与通知数据存储，对于可以直接传入视图层显示的视图层数据，使用SpringBoot开发的监控终端能够通过监听指定KafkaTopic来获取相关的数据，并且存入JVM维护的本地缓存；对于通知数据，若是调度类的通知数据，则进入步骤7进行处理，若是其他通知数据，则缓存到持久化数据层；

步骤6：视图层数据显示，监控系统前端系统可以通过HTTP接口获取静态数据，通过webscoket技术获取源源不断的流数据；同时监控终端还应提供控制接口；

步骤7：应用服务调度，对于调度通知信息，监控终端能够通过监听指定Kafkatopic来获取调度信息，还能够从前端系统获取调度信息，并将这些数据转化为对Zookeeper结点树的对应操作，变更特定的结点；下层子系统监听到结点的变更后，就会调用线程控制器模块，对被监控应用服务进行调度。

与现有技术相比，本发明具有以下有益效果：

本发明提供了基于Kappa架构的监控系统及监控方法，从底层的网络传输层协议出发，使用TCP协议，避免了UDP协议的丢包问题以及HTTP协议的冗余数据问题，同时结合了Reactor反应器设计模式，可以通过增加通信线程数量的方式，在带宽允许的情况下，提高服务器之间数据传输量。被监控集群的各个服务器重要信息都会存储在Zookeeper中，信息能够冗余地存储在集群中，排除单点故障所造成的内存数据丢失问题。由于Kafka的partition分配算法，数据能够被均衡地分布存储在消息引擎当中，在一定程度上，防止数据倾斜现象的发生。

附图说明

图1为本发明优选实施例的各个子系统的部署设计图；

图2为本发明优选实施例的下层子系统功能模块示例表；

图3为本发明优选实施例的中层子系统功能模块示例表；

图4为本发明优选实施例的上层子系统监控终端系统功能模块示例表；

图5为本发明优选实施例的上层子系统传感器功能模块示例表；

图6为本发明优选实施例的Zookeeper结点设计示例表；

图7为本发明优选实施例的数据传感器流处理拓扑示例图；

图8为本发明优选实施例的Kafka各通道主题业务存储设计示例表；

图9为本发明优选实施例的下层子系统启动流程图；

图10为本发明优选实施例的监控系统数据交互流程图。

具体实施方式

下面结合附图及实施例对本发明做进一步说明。

应该指出，以下详细说明都是例示性的，旨在对本申请提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语具有与本申请所属技术领域的普通技术人员通常理解的相同含义。

需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本申请的示例性实施方式；如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式，此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在特征、步骤、操作、器件、组件和/或它们的组合。

一种基于Kappa架构的监控系统，参考图1至10，包括下层子系统、中层子系统和上层子系统；下层子系统由数据采集器、数据通信器和线程控制器构成，涉及到的内容包括Zookeeper监听业务、Netty客户端业务以及Future异步回调技术；中层子系统由数据接收器和数据分类器构成，涉及到的内容包括Netty服务端业务、Zookeeper分布式协调服务和Kafka消息引擎；上层子系统由监控终端和数据传感器构成，涉及到的技术包括SpringBoot服务端、Flink流处理技术。

所述数据采集器包括配置文件IO模块、日志文件读取模块及本地数据管程模块；所述数据通信器包括Netty客户端模块、日志文件版本缓存模块及Zookeeper结点树模块；所述线程控制器包括线程分发模块、线程控制模块、脚本驱动模块及线程状态回滚模块。所述数据接收器包括Netty服务端模块及数据预处理模块；所述数据分类器包括数据分类模块及Kafka发布端模块。

所述数据传感器包括流量计算结点、集群性能计算结点、指标基线告警计算结点以及各个具体业务分析结点；所述监控终端包括Kafka消息订阅端模块、视图层接口模块、集群服务调度模块、资源信息管理模块及监控终端Zookeeper结点树模块。

一种基于Kappa架构的监控方法包括以下步骤：

步骤1：监控数据收集，部署在被监控结点的下层子系统会定时收集本服务器的OS监控数据，应用程序日志数据以及业务逻辑日志数据，并将这些数据以JSON的数据格式通过Netty客户端发送至位于事件路由服务器的中层子系统；与此同时，直接来自业务客户端的本地业务数据也通过Cookie被传输至中层子系统；

步骤2：监控数据预处理，中层子系统将收集到的各类监控流数据以及直接来自用户客户端的数据，通过数据预处理模块，根据策略，补正缺失数据并且过滤的无用数据，同时将经过处理的流数据汇集到本机的数据分类器模块当中；

步骤3：监控数据分类，数据分类器根据数据处理的结果和源数据JSON标记的种类，按照不同的类别、紧急程度以及具体的功能需求，分发到不同的Kafka主题当中；

步骤4：监控数据处理，使用基于yarn管理的Flink集群从Kakfa拉取数据，并对各类数据进行实时分析，生成视图信息，同时根据提前设计好的指标基线，生成通知信息，将不同的处理结果分发到不同的Kafka主题；

步骤5：视图层数据与通知数据存储，对于可以直接传入视图层显示的视图层数据，使用SpringBoot开发的监控终端能够通过监听指定KafkaTopic来获取相关的数据，并且存入JVM维护的本地缓存；对于通知数据，若是调度类的通知数据，则进入步骤7进行处理，若是其他通知数据，则缓存到持久化数据层；

步骤6：视图层数据显示，监控系统前端系统可以通过HTTP接口获取静态数据，通过webscoket技术获取源源不断的流数据；同时监控终端还应提供控制接口；

步骤7：应用服务调度，对于调度通知信息，监控终端能够通过监听指定Kafkatopic来获取调度信息，还能够从前端系统获取调度信息，并将这些数据转化为对Zookeeper结点树的对应操作，变更特定的结点；下层子系统监听到结点的变更后，就会调用线程控制器模块，对被监控应用服务进行调度。

本发明应用到了Netty框架，该框架使用Netty程序自带的ByteBuf缓冲区进行“真正地”读写操作，该ByteBuf缓冲区并不位于JVM堆内，而是由ByteBufAllocator单例类，通过系统调用相关的malloc()函数创建而成，故该ByteBuf缓冲区又被称为直接缓冲区(Direct ByteBuf),比起存储在JVM堆中的HeapByteBuf，DirectByteBuf在写业务上表现优秀。考虑到DirectByteBuf创建销毁开销较大，同时和HeapByteBuf一样有内存溢出问题，并且下层子系统以写业务为主，本发明建议在申请创建DirectByteBuf缓冲区时，采用池化模式。由Netty程序的池化分配器自行管理，在大数据环境下，能够一定程度上有效地避免内存溢出。

本发明应用到了Zookeeper分布式协调系统，该系统的所维护的注册信息将会全部缓存各个Zookeeper服务器中的内存当中，并且是以树形结构进行存储的。故Zookeeper的官方文档明确提到Zookeeper存储树的每一个结点大小不应该操作1M，同时结点树的高度也不应该过大，否则就有可能会影响Zookeeper协调服务的性能。因此在实际开发中，Zookeeper结点树的存储内容需要得到合理的规划。

本发明应用到了Kafka消息引擎架构，由于Kafka所有实际读写操作都是在partitionLeader上执行的，其自带智能的partitionLeader选举算法，该算法能够将partitionLeader分发到不同的物理结点上。从而实现消息引擎层的数据负载均衡业务，在一定程度上避免数据倾斜问题。如果要考虑其他消息引擎系统，则要确保该消息引擎起码具备流重播技术，否则基于Kappa架构开发的系统将难以执行与离线计算相关的业务。

步骤1执行之前首先需要依次做好以下的工作：①初始化下层子系统的各个模块。②初始化Curator客户端与Zookeeper服务器的连接，并注册配置信息。监控终端能够及时监听到下层子系统的注册动作，并且更新监控终端的本地缓存内容。③初始化线程控制器，并从Zookeeper查询到所需启动的应用服务信息，并依次启动需要被监控的的应用程序。④初始化监听Redis发布/订阅通道的工作线程。⑤通过线程控制器启动Netty客户端；以上步骤全部完成以后，数据采集器才能够正常开始工作，采集所需的监控数据，并且分发到中层子系统中。

整套系统的启动服务也具有前提条件，即Zookeeper集群与Kafka集群必须首先启动并且正常运行，否则3个子系统的之间的信息交互就无法完成，监控业务就无法正常实现。

本发明提供了基于Kappa架构的监控系统及监控方法，从底层的网络传输层协议出发，使用TCP协议，避免了UDP协议的丢包问题以及HTTP协议的冗余数据问题，同时结合了Reactor反应器设计模式，可以通过增加通信线程数量的方式，在带宽允许的情况下，提高服务器之间数据传输量。被监控集群的各个服务器重要信息都会存储在Zookeeper中，信息能够冗余地存储在集群中，排除单点故障所造成的内存数据丢失问题。由于Kafka的partition分配算法，数据能够被均衡地分布存储在消息引擎当中，在一定程度上，防止数据倾斜现象的发生。

Claims (1)

1.一种基于Kappa架构的监控系统的监控方法，其特征在于：所述监控系统包括下层子系统、中层子系统和上层子系统；下层子系统由数据采集器、数据通信器和线程控制器构成，涉及到的内容包括Zookeeper监听业务、Netty客户端业务以及Future异步回调技术；中层子系统由数据接收器和数据分类器构成，涉及到的内容包括Netty服务端业务、Zookeeper分布式协调服务和Kafka消息引擎；上层子系统由监控终端和数据传感器构成，涉及到的技术包括SpringBoot服务端、Flink流处理技术；

所述数据采集器包括配置文件IO模块、日志文件读取模块及本地数据管程模块；

所述数据通信器包括Netty客户端模块、日志文件版本缓存模块及Zookeeper结点树模块；

所述线程控制器包括线程分发模块、线程控制模块、脚本驱动模块及线程状态回滚模块；

所述数据接收器包括Netty服务端模块及数据预处理模块；

所述数据分类器包括数据分类模块及Kafka发布端模块；

所述数据传感器包括流量计算结点、集群性能计算结点、指标基线告警计算结点以及各个具体业务分析结点；

所述监控终端包括Kafka消息订阅端模块、视图层接口模块、集群服务调度模块、资源信息管理模块及监控终端Zookeeper结点树模块；

包括以下步骤：

步骤1：监控数据收集，部署在被监控结点的下层子系统会定时收集本服务器的OS监控数据，应用程序日志数据以及业务逻辑日志数据，并将这些数据以JSON的数据格式通过Netty客户端发送至位于事件路由服务器的中层子系统；与此同时，直接来自业务客户端的本地业务数据也通过Cookie被传输至中层子系统；

步骤2：监控数据预处理，中层子系统将收集到的各类监控流数据以及直接来自用户客户端的数据，通过数据预处理模块，根据策略，补正缺失数据并且过滤无用数据，同时将经过处理的流数据汇集到本机的数据分类器模块当中；

步骤3：监控数据分类，数据分类器根据数据处理的结果和源数据JSON标记的种类，按照不同的类别、紧急程度以及具体的功能需求，分发到不同的Kafka主题当中；

步骤4：监控数据处理，使用基于yarn管理的Flink集群从Kafka拉取数据，并对各类数据进行实时分析，生成视图信息，同时根据提前设计好的指标基线，生成通知信息，将不同的处理结果分发到不同的Kafka主题；

步骤5：视图层数据与通知数据存储，对于直接传入视图层显示的视图层数据，使用SpringBoot开发的监控终端能够通过监听指定KafkaTopic来获取相关的数据，并且存入JVM维护的本地缓存；对于通知数据，若是调度类的通知数据，则进入步骤7进行处理，若是其他通知数据，则缓存到持久化数据层；

步骤6：视图层数据显示，监控系统前端系统通过HTTP接口获取静态数据，通过websocket技术获取源源不断的流数据；同时监控终端还提供控制接口；

步骤7：应用服务调度，对于调度通知信息，监控终端能够通过监听指定KafkaTopic来获取调度信息，还能够从前端系统获取调度信息，并将这些数据转化为对Zookeeper结点树的对应操作，变更特定的结点；下层子系统监听到结点的变更后，就会调用线程控制器模块，对被监控应用服务进行调度。