【监控】一些关于应用级别监控的总结

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