1. 采集多样化的必要性,通俗的说就是把软硬件的指标放在一起去比较。

  有时候我们关注应用的运行状态不仅仅要采集应用的各项指标,有时候还需要了解同一时间该应用运行环境(容器、虚拟机、硬件)的关键指标。然而应用层与其运行环境本身异构,所以采集工具并不相同。比如,我们用openTSDB去监控我的一个web程序,而用ganglia去监控了它所在的服务器,其实我们很多时候更加关注软硬件指标在同一时刻时的表现,切来切去太不直观了。这样问题就来了,两种不同的工具分别展示在不同的页面上,能不能把Web程序的指标和服务器的CPU,内存,文件句柄等指标放在一起看呢?

  其实很容易想到分别采集,统一存储就可以了。现在主要做了代码调用度量的SDK(代码嵌入式的监控包),JMX采集(大型开源分布式系统基本都提供),文本协议采集(redis, memcached监控端口,zk stat等),还有硬件指标采集。这些监控数据统一了数据结构,存储在ES或者HBase之中,这样就很容易在UI上面渲染各种异构系统的指标的时间曲线。其实这种需求的根本源于系统之间调用的关系,以及应用在环境中运行的依赖关系。

  在统一的存储结构中,我们很容易定义出各种应用或系统的调用关系和依赖关系,这样,在查询的时候就很容易吧关联指标找到,更容易发现问题。所以结论是,多样化采集+集中存储是需求的必然。

2. 对于监控,除了指标维度、时间维度、统计模型维度之外,还应该有调用依赖维度

怎么说呢?

  以前,我们会关注当前服务器CPU、MEM、DISK的指标值,我们借助一些系统命令去查看,得到的数据是一维的,就是一个指标的值,能够变化的是指标。

  再进一步,我们有一些工具,zenoss这种,可以把带宽消耗、CPU消耗在时间维度上投影,那么得出了一条曲线,这样是二维了:指标变化,时间变化。

  再高级一些,对于一个方法的调用我们可以从各种角度去观察它:调用耗时统计、调用频次、调用计数、调用结果统计,然后打包度量,任何方法都普适的度量模型。这就是指标,时间,模型。模型代表了一套普适统计方法。比如现在很有名的metrics模型:codahale实现的java metrics。

  更细的观测维度是什么呢?对于指标之间,异构系统之间的调用往往是有关系的,所以一组异构系统指标的监测是有必要的。但这里要注意,我们在“1”中说的方式仅仅是把关联的统计指标放在一起去比较,但这样粒度太粗了,真正做到关联指标的观测,需要着眼于调用的级别去观测,在一次调用中,A调用了B,这样的关系不能在时间维度上精确的体现,必须是一一对应才行。所以本质上,这是个新的观测维度。这就是trace系统。

  也就是说,各种被监控的系统在发生每一次调用后都有一个call id,唯一的记录了本次调用。那么这个call关联了两个系统的多个指标。这种模型下,除了定义了调用关系,统计数据是自然而然可以做到的事情。但就实现而言,需要把他集成在通信框架之内才可以做到,因为每次调用是需要精确标记的。

  其实这种思路与我们以前高中生物课本上面的同位素标记法很相似,call id就是同位素,每次调用过程就是一次化学变化的过程。