监控系统的核心模型分析

在开发任何系统一个系统时，我们首先需要透彻分析系统所要解决的问题域，然后将问题域抽象映射到一个或几个关键的业务模型上，这样的业务模型决定了支撑系统的核心数据结构，在此我非专业地将此模型称为系统的核心模型。

没有比监控系统更为清晰的核心模型了。

找出监控系统的核心模型之前，我们首先必须弄清楚做监控的意义是什么？做监控是为了保证正常运营，那我们怎样才能保证运营呢？

我们需要将影响运营的各个关键环节监控起来，及时发现出现的问题和潜在的风险，那我们如何及时发现问题和风险呢？

首先，我们需要确定需要被监控的关键环节，称之为监控对象（object）；

其次，我们要采集监控对象的度量指标值，称之为指标值（value）；

最后，很关键的我们要对监控对象有个评价（例如错误、警告、正常）等，称之为状态（status）；

一句话概括，监控对象就是解决object处于什么status的问题，value作为status的证据和参考比不可少，因此object.status@value是监控系统的核心模型，简称OSV模型。

下面我们来举例说明：

例如我们要监控某服务器的cpu0的使用率，则利用OSV模型可以定义如下：

Object	Value	Status
<服务器>.cpu0	5s中内的平均使用率	正常：[0,<50%] 警告：(50,80] 差：(80,100]

在监控系统中实例化后，就对应到一条监控数据：

Object	Value	Status
(192.168.178.130).cpu0	70%	警告

 

       其实，并不是所有的监控对象都像上述示例中那么简单，有很多监控对象状态的判定需要参考多种指标值，甚至跨监控对象，例如我们监控某台服务器的服务能力：

Object	Value	Status
<服务器>.服务能力	<服务器>.cpu使用率 <服务器>.负载 <服务器>.IOwait <服务器>.内存使用率	正常：所有value的status都为‘正常’ 警告：所有value的status都不为‘差’，且至少一个为‘警告’ 差：任何一value的status为‘差’

在此例中，服务器的服务能力的status取决与监控对象“<服务器>.cpu使用率、<服务器>.负载、<服务器>.IOwait、<服务器>.内存使用率”的status。这也是较为简单的一种，更复杂的有多层监控对象递归和监控对象递归+实际指标数值的情况。

       这说明，在监控系统中监控对象绝非是平面关系，应该是具有层次关系的立体关系。但是无论监控对象间的关系如何复杂，我们都能抽象成OSV模型予以拆解，当然如何监控对象者属于监控系统业务模型分析的范畴，在此暂不加以论述。

       基于OSV模型，我们就能构造出监控对象的核心数据结构，很明显核心数据结构要管理object、value、status信息，从而我们可以将报警信息用统一的数据结构管理起来，实现不同监控对象的统一报警框架。