CN105071950A - 大型分布式智能监控系统 - Google Patents

Abstract

本发明公开了大型分布式智能监控系统，所述系统包括：模拟用户行为模块和应用状态感知模块，所述模拟用户行为模块和所述应用状态感知模块彼此关联协作，由模拟用户行为模块不断循环获取应用的状态，然后将状态传递给应用状态感知模块，应用状态感知模块经过判断，将状态信息以多种方式展示给运维管理人员，实现了监控系统时效性较好的技术效果。

Description

大型分布式智能监控系统

技术领域

本发明及监控系统研究领域，尤其涉及一种大型分布式智能监控系统。

背景技术

随着互联网技术的不断革新及企业规模持续的扩大，企业的信息化建设投入迅速增加，使企业的信息系统越来越复杂，然而传统的服务器管理多采用人工的方式，而该方式存在很多的人力浪费。

同时问题的发现的不够及时，往往错过处理问题的最佳时机。

而服务器出现问题会造成系统负载的增加，应用程序数据处理缓慢，甚至服务器宕机，造成无法挽回的损失。

现在公司的服务器数量庞大，提供的服务越来越多，如果仅靠人力来进行维护，工作量就相当的大，因此就有了大型分布式监控系统的产生。

优点：对设备性能要求低（实际测试环境：虚拟机CentOS5，2GCPU1G内存，监控5台设备，CPU使用率基本保持在10%以下，内存剩余400M以上）；支持设备多；支持分布式集中管理；开放式接口，扩展性强。

缺点：需在被监控主机上安装agent，所有数据都存在数据库里，产生的数据很大,瓶颈主要在数据库。

在现有技术中，传统的监控项目难以反映出各类应用系统是否正常，只有亲自使用系统才能真正判断出应用系统是否可用，单凭人工操作是无法保证监控的时效性的。

综上所述，本申请发明人在实现本申请实施例中发明技术方案的过程中，发现上述技术至少存在如下技术问题：

在现有技术中，由于传统的监控项目难以反映出各类应用系统是否正常，只有亲自使用系统才能真正判断出应用系统是否可用，单凭人工操作是无法保证监控的时效性的，所以，现有的监控系统存在监控的时效性较差，需要大量的人工进行判断的技术问题。

发明内容

本发明提供了一种大型分布式智能监控系统，解决了现有的监控系统存在监控的时效性较差，需要大量的人工进行判断的技术问题，实现了监控系统时效性较好的技术效果。

为解决上述技术问题，本申请实施例提供了大型分布式智能监控系统，所述系统包括：

模拟用户行为模块和应用状态感知模块，所述模拟用户行为模块和所述应用状态感知模块彼此关联协作，由模拟用户行为模块不断循环获取应用的状态，然后将状态传递给应用状态感知模块，应用状态感知模块经过判断，将状态信息以多种方式展示给运维管理人员。

其中，所述模拟用户行为模块根据提取出的用户操作流程，将用户使用应用系统的一系列操作利用程序来自动实现，然后将程序的操作结果记录下来，提供给后续的应用状态感知模块进行判断。

其中，所述应用状态感知模块接受模拟用户行为模块所传递的应用系统状态的信息，分析该状态信息，然后将信息展示给运维管理人员；若出现服务状态的变更，还会以短信、邮件等多种方式实时通知管理员。

其中，所述系统还包括：

网络层模块，所述网络层模块用于提供网络通信接口，方便各模块层通信使用；

服务器模块，所述服务器模块用于提供服务器服务；

Agent模块，所述Agent模块用于搜集被监控服务器的各监控项数据，并根据监控项的监控方式将搜集到的数据发送给监控服务器或者代理服务器；

Proxy模块，所述Proxy模块用于帮助服务器搜集客户端的监控数据，减轻服务器的网络负载；

数据库模块，所述数据库模块用于提供数据库服务。

本申请实施例中提供的一个或多个技术方案，至少具有如下技术效果或优点：

由于采用了将大型分布式智能监控系统设计为包括：模拟用户行为模块和应用状态感知模块，所述模拟用户行为模块和所述应用状态感知模块彼此关联协作，由模拟用户行为模块不断循环获取应用的状态，然后将状态传递给应用状态感知模块，应用状态感知模块经过判断，将状态信息以多种方式展示给运维管理人员的技术方案，即利用运维自动化的核心技术-脚本编程技术来实现，我们采用脚本程序来模拟客户端或用户访问应用系统的流程，将该流程自动化、程序化，利用监控系统的接口将系统状态传递给监控服务器端，通过监控服务器端的Trigger判断，将应用系统的可用状态的变更以页面、邮件或者短信的方式展示给运维管理人员，以达到实时监控的目的，所以，有效解决了现有的监控系统存在监控的时效性较差，需要大量的人工进行判断的技术问题，进而实现了监控系统时效性较好的技术效果。

附图说明

图1是本申请实施例一中大型分布式智能监控系统的组成示意图。

具体实施方式

本发明提供了一种大型分布式智能监控系统，解决了现有的监控系统存在监控的时效性较差，需要大量的人工进行判断的技术问题，实现了监控系统时效性较好的技术效果。

本申请实施中的技术方案为解决上述技术问题。总体思路如下：

采用了将大型分布式智能监控系统设计为包括：模拟用户行为模块和应用状态感知模块，所述模拟用户行为模块和所述应用状态感知模块彼此关联协作，由模拟用户行为模块不断循环获取应用的状态，然后将状态传递给应用状态感知模块，应用状态感知模块经过判断，将状态信息以多种方式展示给运维管理人员的技术方案，即利用运维自动化的核心技术-脚本编程技术来实现，我们采用脚本程序来模拟客户端或用户访问应用系统的流程，将该流程自动化、程序化，利用监控系统的接口将系统状态传递给监控服务器端，通过监控服务器端的Trigger判断，将应用系统的可用状态的变更以页面、邮件或者短信的方式展示给运维管理人员，以达到实时监控的目的，所以，有效解决了现有的监控系统存在监控的时效性较差，需要大量的人工进行判断的技术问题，进而实现了监控系统时效性较好的技术效果。

为了更好的理解上述技术方案，下面将结合说明书附图以及具体的实施方式对上述技术方案进行详细的说明。

实施例一：

在实施例一中，提供了大型分布式智能监控系统，请参考图1，所述系统包括：

模拟用户行为模块和应用状态感知模块，所述模拟用户行为模块和所述应用状态感知模块彼此关联协作，由模拟用户行为模块不断循环获取应用的状态，然后将状态传递给应用状态感知模块，应用状态感知模块经过判断，将状态信息以多种方式展示给运维管理人员。

其中，在本申请实施例中，所述模拟用户行为模块根据提取出的用户操作流程，将用户使用应用系统的一系列操作利用程序来自动实现，然后将程序的操作结果记录下来，提供给后续的应用状态感知模块进行判断。

其中，在本申请实施例中，所述应用状态感知模块接受模拟用户行为模块所传递的应用系统状态的信息，分析该状态信息，然后将信息展示给运维管理人员；若出现服务状态的变更，还会以短信、邮件等多种方式实时通知管理员。

其中，在本申请实施例中，所述系统还包括：

网络层模块

所述网络层模块用于提供网络通信接口，方便各模块层通信使用；网络层模块设计说明：目的：提供一个高效、稳定网络通信接口，方便各模块层通信使用；功能：服务端网络层封装；客户端网格层封装；IOCP支持；CS基础通信协议；命名规则：遵守匈牙利命名法；网络层类图:CDirectNetClient:Client的TCP连接封装；CDirectNetServer:Server的TCP连接封装；

接口说明：

//功能：初始化整个网络系统

DNRESULTInitialize(iDirectNetCryption*cryption,iDirectNetServerEventHandler*handler,DWORDmaxNumberClients)；

//功能：关闭网络连接

VoidClose();

模块主框架设计流程图：网络消息模块流程：调用build初始化-接收消息/发送消息-调用relese。

服务器模块

所述服务器模块用于提供服务器服务；Server模块设计说明

目的：

提供一个高效、稳定服务器模块。

功能：

1.同步数据库的hosts表和items表。

2.检查database是否挂掉。

3.主动连接agent。

4.收数据并处理。

5.alerts表中的未发送的警报都发送。

6.定时对数据库中一些过期的数据进行删除。

7.设置阀值。

8.实现分布式关联函数。

9.周期性的检测服务是否运行正常。

10.收索ip地址范围，它加入hosts表。

11.将history数据同步数据库。

12.发送邮件和执行远程shell命令。

13.主动连接代理，并获取history数据。

14.收集收集系统本身的各个进程的运行情况。

命名规则：

遵守匈牙利命名法

Server模块类图：

iBGDBconfig：同步数据库的hosts表和items表的内容到内存的进程，时间间隔默认为1s，这两个表用的很频繁，出于性能考虑，在内存上用哈希表的形式缓存了这两个表的信息。

iBGWatchdog：检查database是否挂掉，时间间隔默认60s，如挂了需要向管理员报警，检查的方式为每隔60s重连一次数据库，没有报错表明运行正常。

iBGPoller：主动连接客户端，然后发送请求然后获取获取响应的数据，并将获取的数据存放到history表的内存缓存中，同时更新监控项的状态。

iBGTrapper:从监听端口接收数据并调进行处理。

iBGAlerter:每隔30s将alerts表中的未发送的警报都发送出去，并且发送成功后将警报标识改为已发送。

iBGHousekeeper：定时对数据库中一些过期的数据进行清理删除。

iBGTimer：这个进程最主要的功能就是定时的调用计算数据库中定义的触发器的值，如果新值和原有的值不相等，表示有新的事件产生，然后就将新的事件插入到数据库。

iBGDiscoverer：它会扫描定义ip地址范围内的ip，如果发现有新的客户端存在则会将它加入hosts表中

iBGEscalator：将触发器事件和所需执行的动作联系起来的一个表，这个相应动作可以是重复执行的，动作有两个选择：发送邮件和执行远程shell命令；

接口说明：

//获取线程类型

intget_process_info_by_thread(intserver_num,unsignedchar*process_type,int*process_num);

//启动被动方式轮询线程

intpoller_thread(void*args);

//启动主动方式trapper线程

inttrapper_thread(void*args)。

Agent模块

所述Agent模块用于搜集被监控服务器的各监控项数据，并根据监控项的监控方式将搜集到的数据发送给监控服务器或者代理服务器；

设计目的：

本模块设计的目的在于搜集被监控服务器的各监控项数据，并根据监控项的监控方式(主动和被动)将搜集到的数据发送给监控服务器或者代理服务器。

模块功能：

1.搜集客户端基础监控数据：CPU和硬盘

2.通过被动监控方式，被动地等待服务器轮询请求，当服务器请求时将监控数据发送给服务器

3.通过主动监控方式，每隔一段时间主动地与服务器建立连接，获取监控项数据发送给服务器

4.通过在配置文件中配置自定义脚本的KEY值和路径，执行用户自定义脚本

命名规则：

遵守匈牙利命名法

agent模块类图：

iBGCollector：每隔1s收集本机的cpu状态和硬盘状态，存入相应的结构体中。

iBGListener：负责被动监控方式，等待服务端请求并进行响应，将监控数据封装成JSON格式发送给服务器。

iBGActive：负责主动监控方式，主动连接服务器的监听端口，请求监控主机配置信息，并根据配置信息将监控项发送给服务器。

接口说明：

//功能：读取客户端配置文件信息

staticvoidbg_load_config(intrequirement);

//功能：启动collector线程

intcollector_thread(void*args)。

Proxy模块

所述Proxy模块用于帮助服务器搜集客户端的监控数据，减轻服务器的网络负载；

设计目的：

帮助服务器搜集客户端的监控数据，减轻服务器的网络负载，是实现分布式监控的必要模块

模块功能：

1.同步服务端的配置信息，确定需要搜集的主机监控项。

2.周期性发送搜集到的监控数据和主机信息给服务端

3.以轮询的方式周期性连接客户端，搜集以被动方式监控的数据

4.等待客户端主动请求监听端口，搜集以主动方式监控的数据

命名规则：

遵守匈牙利命名法

Proxy模块类图：

iBGProxyconfig：周期性地同步服务端主机列表的配置信息，获取需要收集的监控项目。

iBGDatasender：周期性地将客户端主机的监控数据封装为JOSN格式，发送给客户端

iBGPollerProxy：周期性地连接客户端的监听端口，搜集监控数据，用于被动方式的监控。实现方式同服务端。

iBGTrapperProxy：主动监听客户端的连接请求，发送监控项信息给客户端，并接收客户端搜集的监控数据。实现方式同服务端。

接口说明：

//启动同步信息线程

intproxyconfig_thread(void*args);

//启动数据发送线程

intdatasender_thread(void*args)。

数据库模块，所述数据库模块用于提供数据库服务，

其中，在本申请实施例中，我们在agent和中心服务器之间架设了Proxy层，它会从监控的host获取监控数据，并保存在本地数据库中。在满足一定条件后，会将这些数据发送给监控服务器，再进行后续操作，比如检查是否触发报警。监控服务器会每间隔一段时间将自己的配置同步给Proxy，这样一切的配置都是在监控服务器上配置然后同步到各个Proxy，从而保证了分布式架构下的配置一致性。

在监控系统中，容易出现性能瓶颈的数据库端的操作，使用Proxy以后，相当于一部分压力会由Proxy的数据库承担，并且Proxy发送数据给监控服务器也是分批进行的，能够大大缓解监控服务器压力。

另外，Proxy也能够解决很多网络问题，比如我国的互联网公司一般有多个IDC机房，由于一些原因，机房之间的互联互通并不是那么好，又或者是防火墙的问题造成监控服务器和服务器的网络通信不好，基于此我们在每一个IDC机房部署一个Proxy来监控本机房的服务器，我们只要解决Proxy和监控服务器之间的通信问题就可以了，这在我们的实际应用中是非常合适的。

Hosts表用于存储所有要被监控的主机信息，hostid为主机唯一标识，Items表记录了监控项目信息，如：添加监控项，删除监控项，更新监控项等配置，itemid为监控项唯一标识。Triggers表保存触发报警的条件，一般里面保存的是表达式及报警阀值。Event记录被监控服务器上报的各项信息，这些信息再与triggers表的报警条件进行比对，判断是否应该触发报警。

可能存在风险：跨机房访问，可能存在网络通信问题。监控主机多，监控服务器可能存在处理性能问题。监控项目多，监控中心数据库可能存在性能问题。

监控项目架构较复杂，可能存在客户端自动更新问题。风险解决办法：风险、、采用Proxy层来处理。风险处理办法如下：定期(每周)清除报警日志表。报警日志总表采用Merge引擎，按天分表。监控数据库采用主从机制，所有查询操作在从库上完成。

监控中心主界面

主要作用:

可以将海量大数据进行多层次分类，能较为清晰地体现数据的所属类别，这样可以在选择类别和部分其它查询条件的情况下快速获取需要的数据，从而避免每次都需要从大数据中进行数据筛选。

具体展示

一级菜单栏“监控”项提供监控设备的详细数据，共十项二级菜单，包括：“仪表盘”、“总览”项、WEB项、“最新数据”项、“触发器”项、“事件”项、“图形”项、“多图显示”项、“拓扑图”项、IT服务项。

一级菜单栏“资产”项主要记录被监控设备的配置清单。二级菜单包括资产总览及主机项。

一级菜单栏“报告”项主要提供被监控设备的性能报告。二级菜单包括“可用性报告”、“前100个触发数据”、“柱形图”。

上述本申请实施例中的技术方案，至少具有如下的技术效果或优点：

由于采用了将大型分布式智能监控系统设计为包括：模拟用户行为模块和应用状态感知模块，所述模拟用户行为模块和所述应用状态感知模块彼此关联协作，由模拟用户行为模块不断循环获取应用的状态，然后将状态传递给应用状态感知模块，应用状态感知模块经过判断，将状态信息以多种方式展示给运维管理人员的技术方案，即利用运维自动化的核心技术-脚本编程技术来实现，我们采用脚本程序来模拟客户端或用户访问应用系统的流程，将该流程自动化、程序化，利用监控系统的接口将系统状态传递给监控服务器端，通过监控服务器端的Trigger判断，将应用系统的可用状态的变更以页面、邮件或者短信的方式展示给运维管理人员，以达到实时监控的目的，所以，有效解决了现有的监控系统存在监控的时效性较差，需要大量的人工进行判断的技术问题，进而实现了监控系统时效性较好的技术效果。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (4)

1.大型分布式智能监控系统，其特征在于，所述系统包括：

模拟用户行为模块和应用状态感知模块，所述模拟用户行为模块和所述应用状态感知模块彼此关联协作，由模拟用户行为模块不断循环获取应用的状态，然后将状态传递给应用状态感知模块，应用状态感知模块经过判断，将状态信息以多种方式展示给运维管理人员。

2.根据权利要求1所述的系统，其特征在于，所述模拟用户行为模块根据提取出的用户操作流程，将用户使用应用系统的一系列操作利用程序来自动实现，然后将程序的操作结果记录下来，提供给后续的应用状态感知模块进行判断。

3.根据权利要求1所述的系统，其特征在于，所述应用状态感知模块接受模拟用户行为模块所传递的应用系统状态的信息，分析该状态信息，然后将信息展示给运维管理人员；若出现服务状态的变更，还会以短信、邮件等多种方式实时通知管理员。

4.根据权利要求1所述的系统，其特征在于，所述系统还包括：

网络层模块，所述网络层模块用于提供网络通信接口，方便各模块层通信使用；

服务器模块，所述服务器模块用于提供服务器服务；

Agent模块，所述Agent模块用于搜集被监控服务器的各监控项数据，并根据监控项的监控方式将搜集到的数据发送给监控服务器或者代理服务器；

Proxy模块，所述Proxy模块用于帮助服务器搜集客户端的监控数据，减轻服务器的网络负载；

数据库模块，所述数据库模块用于提供数据库服务。