谈到监控系统,最根本的核心就是数据采集。而谈到数据采集,我们最简单的印象,就是这样一个系统,它最核心的功能是主动轮询或被动接收数据,然后把数据进行存储和各种维度的展现。下面我们从最基本的架构层次来解读一个监控系统的几个部分。
下图是监控系统或者数据采集系统的基本架构
(1)数据采集层
数据采集层是一个监控系统最基本也是最重要的部分。在这个部分,监控系统通过自带的各种采集器完成对客户环境的数据采集。一般来说采集器,分成接触和非接触两种,而采集器采用的协议是根据采集对象和数据类型决定的。数据的采集可以是主动的或者被动的,周期可以是定时或者轮询。
(2)数据处理层
各种采集器完成数据采集后,将进行统一的数据转化和数据处理,比如数据的清洗、筛选、归类以及数据的转换。数据处理完成后将形成时序的性能数据,并存储到数据库中。同时使用者通过系统产生的一些业务数据,也将和性能数据关联,使得采集到的原始数据打上了业务标签。
(3)业务层
业务层是监控系统的核心业务和主要功能层。通过业务层,使用者可以完成和数据采集相关的各种业务功能,如采集对象的增删改、采集参数的配置、策略和规则配置、报表和视图的配置、用户管理和权限配置等等。
(4)展现层
展现层给使用者提供数据、UI操作以及各种视图展现,包括实时的采集数据和状态信息、历史数据和经过聚合的报表数据、各种排序和对比数据,并可以和相关业务系统进行关联,形成更多逻辑视图。
一个简单的监控系统只需要具备上述四种结构层次就基本可以搭建起来。但是在实际应用中,监控系统常常会面临着下面几个挑战:
为了很好地解决以上几个问题,监控系统在设计的过程中需要考虑扩展性设计,一般从下面几个方面来考虑:
由于被监控对象种类众多,而且不断扩充,因此需要对被监控对象进行统一建模。建模方法的扩展性以及建模的容易程度决定了监控系统的扩展性。
统一对象管理可以管理所有可能的被监控对象模型,包括被监控对象的主要属性、监控参数和采集结果定义等,因此在建模的设计上需要考虑特定行业内可能的被监控对象的抽象性和通用性。对象的模型定义不仅需要考虑实体对象,也需要考虑虚拟对象,如逻辑对象等。
如果可能,系统最好提供一些使用简单的UI界面、傻瓜化的操作或者是简单的模型定义语言,来允许使用者自己建造自有模型。
由于被监控对象种类众多,而且不断扩充,被监控对象的指标也种类众多,不断扩充。所以尽可能需要在设计上考虑通用采集器,一个采集器可以满足多个种类的数据采集,只需要传入一些关键性的参数就可以变换成适合不同对象不同指标的采集器。比如针对操作系统,可以支持多种采集脚本的采集器,想采集什么内容,只需要传入特定的脚本就可以实现;对于SNMP设备,可以支持自定义oid并能支持mib加载的采集器,只需要指定特定oid就变成了特定的采集器;对于数据库,可以支持自定义SQL语句的采集器,只需要传入自己写的SQL语句就完成了特定的采集。
有了通用采集器,就可以最大限度增加数据采集的兼容性。当出现新的被监控对象时,可以以最小的开发成本和最快的速度完成数据采集的对接。
同样如果可能,系统最好我们可以提供一些使用简单的UI界面、傻瓜化的操作I或者设计语言等方式来实现通用采集器的扩展。
海量采集是监控系统必须面对的场景。针对海量的被监控对象,除了提高单台监控系统的硬件配置,一个最常见的解决方案就是集中管理分散采集的分布式监控系统。
被监控对象的管理和配置以及所有业务流程都集中管理,使用者只需要登录一个入口就可以完成所有的操作,所有配置数据和采集结果也将集中存储。
大规模采集方案将配置多台采集服务器并支持横向扩展。每台采集服务器将负责部分采集任务,并将采集结果统一上传到集中数据存储。
在多台采集服务器和集中管理端可以增加消息中间件来做为缓冲,提高消息传递性能,降低系统瓶颈。
PIGOSS BSM监控系统在扩展性设计上充分考虑以上几个方面。BSM监控系统自带CMDB管理模块,通过XML定义完成对被监控对象的统一建模。模型包括被监控对象的资源定义和指标定义。一个新资源的建模可以在半天内完成。
图:监控资源模型和指标定义
BSM监控系统提供了多种通用采集器,并提供界面支持对陌生设备的扩展监控,即自定义采集器,包括:
图:自定义Snmp OID指标