一种自动调度的分布式数据监控系统及方法与流程

1.本发明属于监控系统技术领域，具体涉及一种自动调度的分布式数据监控系统及方法。


背景技术：

2.在云计算和物联网系统中，各个业务模块之间需要协同工作，其内部数据呈现出异构性，松耦合等特点。这些系统都需要稳定可用的监控系统保证其健康性以及稳定性。数据监控系统在保障数据安全和数据服务质量方面起着重要的作用，因此对监控系统的研究是非常有意义的。
3.普通监控系统一般采用数据接口模式，通过第三方服务向监控系统推送数据，或者监控系统从第三方服务拉取数据，然后在监控系统中进行集中式规则计算，从而判定是否告警。此种架构的设计，当对接的第三方服务数据点位较多，需要对数据进行运算的告警规则较多的时候，监控系统无论在数据接入方面还是从数据处理方面都很容易到达性能瓶颈，系统扩展性也性对较弱。


技术实现要素：

4.为了克服上述现有技术存在的不足，本发明提供了一种自动调度的分布式数据监控系统及方法。
5.为了实现上述目的，本发明提供如下技术方案：一种自动调度的分布式数据监控系统，包括：nginx反向代理服务器，与被监控对象通过http协议、mqtt协议和websocket协议通信连接；多个告警规则模块，采用master-slaver架构进行部署，多个所述告警规则模块均与所述nginx反向代理服务器通过http协议连接；kafka队列，与多个所述告警规则模块通过http协议连接；多个告警计算模块，通过zookeeper服务器，以tcp协议方式连接；每个所述告警计算模块均与所述kafka队列通信连接。
6.优选的，所述master-slaver架构包括：多个slaver节点，与zookeeper服务器通信连接；用于计算业务；master节点，与zookeeper服务器通信连接；主要用于管理多个slaver节点，同时也承担计算业务。
7.优选的，还包括：mysql数据库，与多个所述告警规则模块通信连接；时序数据库opentsdb，与kafka队列和多个所述告警计算模块通信连接；集中式缓存模块，与kafka队列和多个所述告警计算模块通信连接。
8.一种自动调度的分布式数据监控方法，包括以下步骤：
nginx反向代理服务器获取被监控对象的监控请求，将监控请求存储在时序数据库opentsdb；当出现告警规则模块宕机时，对多个告警规则模块重新部署；否则，多个告警规则模块根据监控对象的监控请求，分别制定告警规则和多维度的数据逻辑模型，并将多个告警规则和数据逻辑模型存储在mysql数据库；kafka队列对多个告警规则模块和多个告警计算模块进行解耦；多个告警规则和数据逻辑模型进入kafka队列；zookeeper服务器协调多个告警计算模块从kafka队列分别获取各自维护的告警规则和数据逻辑模型，多个告警计算模块分别根据告警规则和数据逻辑模型运算，并行得到多个监控告警结果；监控告警结果通过kafka队列推送给被监控对象或第三方系统。
9.优选的，所述当出现告警规则模块宕机时，对多个告警规则模块重新部署的步骤包括：当master节点的告警规则模块上的检测集群检测到slaver宕机；master节点的告警规则模块从zookeeper服务器获得宕机的slaver告警规则模块的ip地址；master节点的告警规则模块从集中式缓存模块的缓存数据中获取宕机的slaver告警规则模块的ip地址对应的告警规则；master节点的告警规则模块将宕机机器的ip地址对应的告警规则发送至kafka队列；master节点的告警规则模块和存活的slaver告警规则模块组成新的master-slaver架构。
10.优选的，所述当出现告警规则模块宕机时，对多个告警规则模块重新部署的步骤包括：当任一个slaver节点的告警规则模块上的检测集群检测到master节点的告警规则模块宕机；zookeeper服务器选取一个slaver告警规则模块作为新的master告警规则模块；新的master告警规则模块从zookeeper服务器获得宕机的master告警规则模块的ip地址；新的master告警规则模块从缓存获取宕机的master告警规则模块的ip地址对应的告警规则；新的master告警规则模块将宕机的master的ip地址对应的告警规则发送kafka队列；新的master节点的告警规则模块和多个slaver告警规则模块组成新的master-slaver架构。
11.优选的，多个告警计算模块分别根据告警规则和数据逻辑模型运算，并行得到多个监控告警结果的步骤包括：告警计算模块将数据逻辑模型转换为监控请求，从监控请求获得被监控对象的数据；告警计算模块利用告警规则对被监控对象的数据进行运算，得到监控告警结果。
12.优选的，所述多个告警规则和数据逻辑模型进入kafka队列的步骤包括：多个告警规则和数据逻辑模型从多个告警规则模块进入kafka队列。
13.优选的，所述多个告警规则和数据逻辑模型进入kafka队列的步骤包括：多个告警规则和数据逻辑模型从mysql数据库加载进入kafka队列。
14.优选的，所述数据逻辑模型包括：多个namespace，所述namespace的数目由被监控对象的监控请求决定；多个metric，分别从属于多个所述namespace；所述metric的数目由被监控对象的监控请求决定；多个dimension，分别从属于多个所述metric；所述dimension的数目由被监控对象的监控请求决定。本发明提供的自动调度的分布式数据监控系统及方法具有以下有益效果：（1）高可用性，具体是对于大数据量环境下的可用性，本分布式系统设计使系统在单位时间内处理的告警数量更多。从而可以满足系统在大数据业务状态下的应用。（2）高可靠性，在分布式集群的架构设计中，任意一个告警计算节点宕机，其维护计算的高级规则集合都会动态转移到其他计算节点下。从而保证在负责环境下，不因为硬件的不稳定造成系统内存数据的丢失。（3）告警规则系列度配置性，本发明可以从不同时间粒度，以及不同的告警计算方法上，对不同的监控对象建立多维度的告警规则配置，从而满足复杂场景下对监控对象不同需求的告警监控。
附图说明
15.为了更清楚地说明本发明实施例及其设计方案，下面将对本实施例所需的附图作简单地介绍。下面描述中的附图仅仅是本发明的部分实施例，对于本领域普通技术人员来说，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
16.图1为本发明实施例1的自动调度的分布式数据监控系统的结构；图2为本发明实施例1的一种自动调度的分布式数据监控方法的流程图；图3为本发明实施例1的告警规则生产消费图；图4为本发明实施例1的slaver宕机告警规则流转图；图5为本发明实施例1的master宕机告警规则流转图；图6为本发明实施例1的告警计算模块交互图；图7为本发明实施例1的数据逻辑模型树状结构图。
具体实施方式
17.为了使本领域技术人员更好的理解本发明的技术方案并能予以实施，下面结合附图和具体实施例对本发明进行详细说明。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。
18.在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、“内”、“外”、“轴向”、“径向”、“周向”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明的技术方案和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。
19.此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。在本发明的描述中，需要说明的是，除非另有明确的规定或限定，术语“相连”、“连接”应作广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体式连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以是通过中间媒介间接相连。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上，在此不再详述。
20.实施例1参阅图1，一种自动调度的分布式数据监控系统，包括：nginx反向代理服务器、多个告警规则模块、kafka队列、多个告警计算模块、mysql数据库、时序数据库opentsdb、和集中式缓存模块。其中，nginx反向代理服务器与被监控对象通过http协议、mqtt协议和websocket协议通信连接。多个告警规则模块采用分布式负载均衡方式进行部署，多个告警规则模块均与nginx反向代理服务器通过http协议连接。kafka队列与多个告警规则模块通过http协议连接。多个告警计算模块通过zookeeper服务器，以tcp协议方式连接。mysql数据库与多个告警规则模块通信连接。时序数据库opentsdb，与kafka队列和多个告警计算模块通信连接。集中式缓存模块与kafka队列和多个告警计算模块通信连接。
21.在本实施例中，分布式负载均衡方式为master-slaver的架构，master-slaver的架构包括：多个slaver节点和master节点。其中，多个slaver节点与zookeeper服务器通信连接，用于计算业务。master节点与zookeeper服务器通信连接，主要用于管理多个slaver节点，同时也承担计算业务。
22.参阅图2，一种自动调度的分布式数据监控方法，包括以下步骤：nginx反向代理服务器获取被监控对象的监控请求，将监控请求存储在时序数据库opentsdb；当出现告警规则模块宕机时，对多个告警规则模块重新部署；否则，多个告警规则模块根据监控对象的监控请求，分别制定告警规则和多维度的数据逻辑模型，并将多个告警规则和数据逻辑模型存储在mysql数据库；kafka队列对多个告警规则模块和多个告警计算模块进行解耦；多个告警规则和数据逻辑模型进入kafka队列；zookeeper服务器协调多个告警计算模块从kafka队列分别获取各自维护的告警规则和数据逻辑模型，多个告警计算模块分别根据告警规则和数据逻辑模型运算，并行得到多个监控告警结果；监控告警结果通过kafka队列推送给被监控对象或第三方系统。
23.在本实施例中，告警规则模块主要负责告警规则的制定以及维护监控对象的数据管理，通过局域网或者广域网的http请求来对用户关注的监控对象根据实际需求建立一系列警规则建模。本实施例中，可以配置告警阈值，支持“大于”，“大于等于”，“小于”，“小于等于”等阈值计算规则，数据聚合方式支持sum，average，max，min，variance。告警规则可以配置被监控数据的计算周期，以及配置计算结果超出阈值的次数。
24.告警计算模块采取分布式架构之后，每个告警计算模块单节点只维护告警规则的子集，则若某一个节点宕机，理论上其维护的告警规则子集会全部丢失，从而造成系统不可靠。如图3所示。
25.本专利采用的利用zookeeper的服务协调能力，采取主从模式，主节点会对所有节点进行管理，当检测到有slaver宕机之时，会获取宕机机器的ip地址等信息，通过这些信息，master节点在缓存或者数据库中匹配到该ip地址对应的所有告警规则，然后把这台宕
机节点上的告警规则集合重新发送到kafka队列中。其他存活的告警规则计算节点，对消息队列重新进行消费，随机无序的消费这些告警规则集合的子集。进而，剩余的其他告警规则计算节点在消费完消息队列之后仍然可以维护告警规则的全集，从而使分布式系统具有高度可靠性。
26.参阅图4，对多个告警规则模块重新部署的步骤包括：当master节点的告警规则模块上的检测集群检测到slaver宕机；master节点的告警规则模块从zookeeper服务器获得宕机的slaver告警规则模块的ip地址；master节点的告警规则模块从集中式缓存模块的缓存数据中获取宕机的slaver告警规则模块的ip地址对应的告警规则；master节点的告警规则模块将宕机机器的ip地址对应的告警规则发送至kafka队列；master节点的告警规则模块和存活的slaver告警规则模块组成新的master-slaver架构。
27.参阅图5，当出现告警规则模块宕机时，对多个告警规则模块重新部署的步骤包括：当任一个slaver节点的告警规则模块上的检测集群检测到master节点的告警规则模块宕机；zookeeper服务器选取一个slaver告警规则模块作为新的master告警规则模块；新的master告警规则模块从zookeeper服务器获得宕机的master告警规则模块的ip地址；新的master告警规则模块从缓存获取宕机的master告警规则模块的ip地址对应的告警规则；新的master告警规则模块将宕机的master的ip地址对应的告警规则发送至kafka队列；新的master节点的告警规则模块和多个slaver告警规则模块组成新的master-slaver架构。
28.由于开源时序数据库opentsdb的存储的逻辑结构中有以下几部分：metric、tags、value、timestamp，对数据进行建模后，其中监控数据逻辑模型中的namespace与dimension都需同时要转换为opentsdb存储逻辑中的tags，监控数据逻辑模型中的metric转换为opentsdb中的metric。再将采集的数据数值按照tags和metric以及时间序列存储在tsdb数据库中。
29.如图6所示，告警计算模块根据告警规则和数据逻辑模型运算得到监控告警结果的步骤包括：告警计算模块将数据逻辑模型转换为监控请求，从监控请求获得被监控对象的数据；告警计算模块利用告警规则对被监控对象的数据进行运算，得到监控告警结果。
30.在本实施例中，多个告警规则和数据逻辑模型进入kafka队列的步骤包括两种：多个告警规则和数据逻辑模型从多个告警规则模块进入kafka队列。多个告警规则和数据逻辑模型从mysql数据库加载进入kafka队列。
31.告警计算模块作为kafka队列的消费者，从kafka队列总消费告警规则，将告警规则存储在本进程的内存中，然后定时器任务根据告警规则中的告警计算周期对告警数据进行定时计算。kafka队列中维护着整个系统告警规则的全集，而每个告警计算模块进程消费到的是告警规则的子集，这样大大降低了每一个告警计算模块的负载，从而可以保证系统健康稳定的运行。
32.在本实施例中，数据逻辑模型包括：多个namespace、多个metric和多个dimension。其中，多个metric分别从属于多个namespace，多个dimension分别从属于多个metric。namespace、metric和dimension的数目均由被监控对象的监控请求决定。参阅图7，例如被监控对象为一套物联网系统，其中有两个子系统subsystem-1，subsystem-2，则subsystem-1与subsystem-2为两个不同的namespace。监控系统需要监控物联网系统中的温度和设备转速，则metric为temperature和speed，在subsystem-1中是监控区域1中的设
备1，此时subsystem-1中的metric均会对应两个维度的dimension，分别可以命名为area-1和device-1，subsystem-2只有一个区域，系统监控设备2上的数据，则其dimension就只有一个维度为device-2。
33.以上实施例仅为本发明较佳的具体实施方式，本发明的保护范围不限于此，任何熟悉本领域的技术人员在本发明披露的技术范围内，可显而易见地得到的技术方案的简单变化或等效替换，均属于本发明的保护范围。