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就是同位素，每次调用过程就是一次化学变化的过程。
