设备综合监控系统架构的制作方法

本发明涉及电信、电力、金融领域设备的数据采集、处理、汇总，具体的说是涉及一种设备综合监控系统架构。

背景技术：

伴随企业信息化进程不断深入，企业IT系统日渐复杂，IT系统的运营、维护和监管难度不断加大。与此同时，企业业务对IT系统的依赖性越来越强，IT已经成为很多业务流程的核心部分甚至是某些业务赖以运行的基础。同时，传统分专业和应急式的监控管理架构已不能适应越来越多用户的要求，需要有集中化、端到端的监控管理解决方案。

多专业、层次化、以及设备类型的多样化，造成管理信息内容差别较大，数据量过大，企业缺乏有效的技术手段掌控全网全专业健康情况，急需告警标准化、分析、压缩、关联和收敛能力。

面向业务和面向业务客户感知运营的转变，要求有针对故障涉及的 IT 资源和服务的分析，便于确定故障影响范围，快速处理故障。

国内监控系统存在的一些问题；

现状一：IT运维成本偏高

据专业调查，企业最关心的是IT运维成本过高。原因是在过去的5年中,很多企业都实施了很多IT系统,使到IT运行越来越复杂,也越来越难管理。IT运维成本过高的一个原因是IT运维的自动化做得还不够好,依靠手工流程来管理,不但使到运维效率不高,而且人力成本更是花费惊人。

现状二：处在“救火式”的IT运维控制

目前，国内在IT运维过程中,IT员工大多数只是处在被动低效率手工救火的状态,只有当事件已经发生并已造成业务影响时才能发现和着手处理。

现状三：简单的自动化程度起了“反作用”

尽管IT运维管理的技术在不断进步,但实际上很多IT运维人员并没有真正解脱出来，主要原因是目前的自动化不高而导致的。目前的技术虽然能够获取IT设备、服务器、网络流量,甚至数据库的警告信息,但成千上万条警告信息堆积在一起更本没法判断问题的根源在哪里。

现状四：各子公司或子系统信息孤岛，无法共享数据

这个问题主要是发生在拥有许多子公司或者子系统的企业，每个子公司或者子系统都是独立的，都单独建设和维护自己的核心业务系统，都各自配备开发人员和维护人员。

技术实现要素：

针对现有技术中的不足，本发明要解决的技术问题在于提供了一种设备综合监控系统架构。

为解决上述技术问题，本发明通过以下方案来实现：设备综合监控系统架构，所述设备综合监控系统架构包括数据采集层、数据处理层、数据展示层；

所述数据采集层包括数据采集引擎、数据采集脚本、监控配置文件的自动生成；

-所述数据采集引擎实现对至少包括系统CPU、磁盘、网络方面参数的基本系统监测，监测至少包括SMTP、POP3、HTTP各种基本的服务类型，通过插件的安装和监测脚本自定义用户针对自己的应用程序实现监测，并针对大量的监测主机和多个对象部署层次化的监测架构；

-所述数据采集脚本设置为自定义脚本采集，针对不同设备进行不同的脚本处理；

-所述监控配置文件描述了数据采集引擎以何种方式执行数据采集脚本，以及传递给脚本的各个性能参数；

所述数据处理层包含CMDB库数据处理模块、业务引擎和数据采集引擎监控配置文件传输模块、数据采集引擎和业务引擎的采集数据传输模块、告警数据的分析处理模块；

-所述CMDB库数据处理模块包含系统能监控的设备的类型、型号、协议、监控命令、阀值信息，另外一部分为企业私有数据，包含设备的名称、ip、所处位置；

-所述配置文件传输模块读取数据库的配置信息，生成监控配置文件，并将业务引擎里的文件传送至数据采集引擎；

-所述采集数据传输模块将数据采集引擎获取的数据经过处理加工传送至业务引擎；

-所述告警数据的分析处理模块采集告警数据，并将告警数据过滤、压缩、分析，减少告警次数，并结合告警的发送规则通知运维人员；

所述数据展示层包含数据的展示，该数据的展示即电脑终端页面的展示；

所述设备综合监控系统架构的流程操作步骤如下：

步骤一、CMDB录入及页面展示：

a、系统初始化：系统提供用户、角色、权限、各类报表展示基础服务，以及提供各种设备的类型、型号、监控协议，监控处理脚本命令为后续监控做好基础数据；

b、CMDB梳理：系统提供手机及电脑端页面入口，企业将梳理好的现有基础设施配置信息，基础设施配置信息包含设备名称、ip、设备型号、业务分类、地理位置，基础设施配置信息通过web页面录入到系统中，形成企业自己的CMDB信息库，根据设备的类型信息对设备本身的常用核心监控性能参数进行监控；

c、运维规则定义：设备告警及巡检规则的定义，根据实际需要定时或实时接收设备告警，及每天由系统帮助完成所有设备的巡检；

d、数据呈现：根据基础配置及采集到的数据，再呈现到前端页面，供企业用户直观，快速的查找和使用系统中的各种实时、历史性能数据；

步骤二、系统标准化：系统接收到用户录入的各种配置信息，梳理成格式存储到数据库，以供后续设备添加监控，及生成各类报表使用；

步骤三、读取生成配置文件：

a、将数据采集引擎和业务引擎分别放置到不同的设备上，先在业务引擎上读取设备相关的配置信息，并按照数据采集引擎能够识别的数据格式生成文件，并传送至数据采集引擎上；

b、设备配置信息包含设备的ip、设备名称、采集的频率、时间、需要的性能数据项及采集该项该使用何种监控命令；

步骤四、FTP上传：数据采集引擎和业务引擎通讯采用ftp协议；

步骤五、格式化：

a、设备监控配置文件一旦上传至采集服务器，即可开始对设备进行自定义监控，采集到的信息需要格式化步骤对数据进行处理；

b、采集到的信息格式化处理后放入到业务数据库中，供业务逻辑层展示设备的实时、历史数据，以及对告警模块提供原始数据；

步骤六、告警引擎分析处理：设备告警需要保证告警的实时性、准确性，原始的告警需要告警引擎过滤、压缩，分析系列步骤得到真正的根源告警；

步骤7、告警发送：获取到的告警需要实时或者定时的通过邮件、短信或者微信的方式通知运维人员，需要将告警和告警策略结合。

2.根据权利要求1所述的设备综合监控系统架构，其特征在于：所述自定义脚本采集根据设备类型的不同，采用不同的数据及通讯协议与设备进行交互，设备直接通过脚本通信或需要加入转换设备进行间接通讯。

3.根据权利要求1所述的设备综合监控系统架构，其特征在于：所述采集数据传输模块的数据处理过程如下：

步骤一，解析数据：将每一个设备监控项的数据，以及每一个监控项反馈的数据，解析成带有关系的数据存放至业务数据库中；

步骤二，数据存储：中心采集服务器将处理的数据和业务数据库里面的基础CMDB库信息进行比对，结合业务需要，丰富处理的数据，放入至业务数据表中，供业务引擎调用。

4.根据权利要求3所述的设备综合监控系统架构，其特征在于，在步骤二中，数据存储主要分为三个流向：

a)告警数据：系统提供单独的告警处理模块，根据监控项状态值，判断设备是否有告警，告警处理模块对告警数据进行分析、加工、发送邮件、短信、微信给运维人员；

b)实时数据：实时数据为了便于展示系统中任意设备的实时状态，快速了解系统设备的整体运行状况；

c)历史数据：历史数据为运维工作，系统升级提供数据支撑，追溯设备运行状态。

相对于现有技术，本发明的有益效果是：

实时性：告警数据量巨大，需要有良好的告警采集处理手段确保实时性；

标准化：各专业、各厂家告警字段定义不同，梳理告警需要有大量的工作；

集中化：扁平化的管理结构，在告警标准化的基础上，统一处理各个专业的告警，需要明确告警关联及预处理规则；

影响性分析：在告警集中化的基础上，明确告警、IT资源和业务的关联关系，建立起告警影响性分析的模型。

1.自动化巡检，CMDB信息库的梳理等功能，减少人工，使运维人员快速得到系统信息，诊断排查故障，降低运维成本

2.结合组织架构实时，定时告警机制，使告警准确实时的发送至运维人员和相关人员，快速协调资源解决故障，提供历史数据和趋势分析，对设备状态进行准确估计，提高运维质量。

3.告警关联分析，过滤，减少告警数量，提供手机入口对告警进行处理，移动办公，加快处理流程，提高效率。

4．可以将各子公司，子系统的设备统一管理，数据共享，减少开发和维护人员，减少维护成本，便于管理。

附图说明

图1为本发明设备综合监控系统架构图；

图2为本发明实施例1中的网络打印机监控管理原理图；

图3为本发明实施例2中的windows系统监控管理原理图；

图4为本发明实施例3中的投影仪监控管理原理图；

图5为本发明实施例4中的无网络接口温湿度传感器采集原理示意图；

图6为本发明实施例4中的设备本身带有网络接口的温湿度传感器采集原理示意图；

图7为本发明实施例5中的数据库监控原理图；

图8为本发明实施例6中的J2EE中间件TOMCAT、WEBLOGIC监控原理图；

图9为本发明实施例7中的采集数据的处理和传输原理图。

具体实施方式

下面结合附图对本发明的优选实施例进行详细阐述，以使本发明的优点和特征能更易于被本领域技术人员理解，从而对本发明的保护范围做出更为清楚明确的界定。

请参照附图1，本发明的设备综合监控系统架构，所述设备综合监控系统架构包括数据采集层1、数据处理层2、数据展示层3；

所述数据采集层1包括数据采集引擎9、数据采集脚本8、监控配置文件的自动生成；

-所述数据采集引擎9实现对至少包括系统CPU、磁盘、网络方面参数的基本系统监测，监测至少包括SMTP、POP3、HTTP各种基本的服务类型，通过插件的安装和监测脚本自定义用户针对自己的应用程序实现监测，并针对大量的监测主机和多个对象部署层次化的监测架构；

-所述数据采集脚本8设置为自定义脚本采集，针对不同设备进行不同的脚本处理；

-所述监控配置文件描述了数据采集引擎以何种方式执行数据采集脚本，以及传递给脚本的各个性能参数；

所述数据处理层2包含CMDB库数据处理模块、业务引擎和数据采集引擎9监控配置文件传输模块12、数据采集引擎9和业务引擎的采集数据传输模块、告警数据的分析处理模块；

-所述CMDB库数据处理模块包含系统能监控的设备的类型、型号、协议、监控命令、阀值信息，另外一部分为企业私有数据，包含设备的名称、ip、所处位置；

-所述配置文件传输模块12读取数据库的配置信息，生成监控配置文件，并将业务引擎里的文件传送至数据采集引擎9；

-所述采集数据传输模块将数据采集引擎9获取的数据经过处理加工传送至业务引擎；

-所述告警数据的分析处理模块采集告警数据，并将告警数据过滤、压缩、分析，减少告警次数，并结合告警的发送规则通知运维人员；

所述数据展示层3包含数据的展示，该数据的展示即电脑终端页面的展示；

所述设备综合监控系统架构的流程操作步骤如下：

步骤一、CMDB录入及页面展示：

a、系统初始化：系统提供用户、角色、权限、各类报表展示基础服务，以及提供各种设备的类型、型号、监控协议，监控处理脚本命令为后续监控做好基础数据；

b、CMDB梳理：系统提供手机及电脑端页面入口，企业将梳理好的现有基础设施配置信息，基础设施配置信息包含设备名称、ip、设备型号、业务分类、地理位置，基础设施配置信息通过web页面13录入到系统中，形成企业自己的CMDB信息库，根据设备的类型信息对设备本身的常用核心监控性能参数进行监控；

c、运维规则定义：设备告警及巡检规则的定义，根据实际需要定时或实时接收设备告警，及每天由系统帮助完成所有设备的巡检；

d、数据呈现：根据基础配置及采集到的数据，再呈现到前端页面，供企业用户直观，快速的查找和使用系统中的各种实时、历史性能数据；

步骤二、系统标准化：系统接收到用户录入的各种配置信息，梳理成格式存储到数据库，以供后续设备添加监控，及生成各类报表使用；

步骤三、读取生成配置文件：

a、将数据采集引擎9和业务引擎分别放置到不同的设备上，先在业务引擎上读取设备相关的配置信息，并按照数据采集引擎9能够识别的数据格式生成文件，并传送至数据采集引擎9上；

b、设备配置信息包含设备的ip、设备名称、采集的频率、时间、需要的性能数据项及采集该项该使用何种监控命令；

步骤四、FTP上传：数据采集引擎9和业务引擎通讯采用ftp协议；

步骤五、格式化：

a、设备监控配置文件一旦上传至采集服务器，即可开始对设备进行自定义监控，采集到的信息需要格式化步骤对数据进行处理；

b、采集到的信息格式化处理后放入到业务数据库中，供业务逻辑层展示设备的实时、历史数据，以及对告警模块提供原始数据；

步骤六、告警引擎分析处理：设备告警需要保证告警的实时性、准确性，原始的告警需要告警引擎过滤、压缩，分析系列步骤得到真正的根源告警；

步骤7、告警发送：获取到的告警需要实时或者定时的通过邮件、短信或者微信的方式通知运维人员，需要将告警和告警策略结合。

以下用几个实施例对本发明作详细的说明。

自定义的采集脚本根据设备类型的不同，采用不同的数据及通讯协议与设备进行交互，有的设备可以直接通过脚本通信，有的则需要加入转换设备进行间接通讯。下面针对综合监控系统现有能采集的几类代表性设备及脚本详细描述。

实施例1：网络打印机监控4，如图2所示，当前使用广泛的打印机大多属于网络打印机，且支持通过SNMP（简单网络管理协议）进行管理，采集脚本通过标准的SNMP协议与打印机SNMP服务端通讯，通过发送OID(对象标识符)获取墨量，是否卡纸，打印纸张数量。

实施例2：windows系统监控5，如图3所示，windows服务器由于安装使用维护方便，在企业中使用较为 广泛，系统同样提供了一些管理接口获取系统的性能参数，如cpu，内存，硬盘等使用情况，由于系统提供的接口获取的数据无法直接进行网络传输，所以需要在windows系统中装入插件，借用插件采集数据并通过网络通讯将采集到的数据发送到中心采集服务器中，以此达到监控的目的。

实施例3：投影仪监控5，如图4所示，投影仪一般需要通过遥控器开机和关机的功能，行业内此类设备大多提供RS-232接口即串口控制接口，利用此接口可以通过中控等设备发送232控制码来操作投影仪设备,通过此接口，按照厂商提供的专用协议，也可以采集到投影仪的性能参数，如投影仪的亮度，分辨率，灯泡时长等，同样的，RS232数据需要进行网络传输，这样就需要一个“RS232转TCP/IP”的转换器将数据响应到数据请求端。

实施例4：温湿度传感器6，如图5-6所示，各类传感器设备在环境监控中起了很大的作用，如温度，湿度，压力，二氧化碳浓度，噪音等等涉及到一系列传感器，传感器感知外界的环境，设备本身如果内置网络通讯接口则可以直接通过网络将数据发送至中心采集服务器上，设备本身如果不带网络，则需要加一个modbus转tcp/ip的网关辅助将数据传送到采集服务器上。

实施例5：数据库监控，如图7所示，由于数据库都是通过sql来操作的，如数据的增删改查，包括数据库的性能指标，由于各数据库厂商体系结构和表结构不一样，所以相应的性能参数和名称都不一样，但总体而言，都是通过发送sql语句获取数据。

实施例6：J2EE中间件Tomcat,Weblogic监控，如图8所示，J2EE平台由一整套服务（Services）、应用程序接口（APIs）和协议构成，它对开发基于Web的多层应用提供了功能上的支持。其中Java Management Extensions (JMX, Java管理扩展) 是一个为应用程序，设备，系统等植入管理功能的框架,Tomcat等中间件厂商都提供了JMX的协议实现，采集脚本只需要遵循JMX协议规范，与上述中间件JMX接口通讯即可查询中间件运行状况。

实施例7：如图9所示，将采集引擎获取的数据经过处理加工传送至业务引擎中去。下面将详细描述数据处理过程。

1.解析数据：

如此众多设备的数据，通过网络传递至采集服务器，为了便于统一管理每一个设备监控项的数据，每一个监控项反馈的数据包含设备的名称，ip，监控项名称，输出内容（性能数据）和一个状态值（反应设备好坏）等，输出内容为文本，不便于后续数据的展示，排行，及部分计算，所以需要解析成带有关系的数据存放至业务数据库中

2.数据存储：

中心采集服务器将处理的数据和业务数据库里面的基础CMDB库信息进行比对，结合业务需要，丰富处理的数据，放入至业务数据表中，供业务处理引擎调用。数据存储主要分为三个流向。

a)告警数据。系统提供单独的告警处理模块，根据监控项状态值，可以判断设备是否有告警，告警处理模块对告警数据进行分析，加工，发送邮件，短信，微信给运维人员。

b)实时数据。实时数据为了便于展示系统中任意设备的实时状态，快速了解系统设备的整体运行状况。

c)历史数据。历史数据为运维工作，系统升级提供数据支撑，追溯设备运行状态，便于快速了解系统设备历史运行状态。

以上所述仅为本发明的优选实施方式，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。