【监控】天机镜——优土大数据平台应用级别监控利器

上古十大神器之一天机镜：天机镜又名昆仑镜。昆仑山西王母全部，能洞察天机，知晓古今！

 

1. 动机

　　在业务系统开发的前期，咱们每每只专一到业务逻辑，而忽略了对系统自己的监控。 对硬件资源的监控运维同窗提供的ganglia以及ZENOSS 能很好的知足咱们的需求，监控机器的磁盘、cpu负载，内存，load，链接数等等。可是介于核心功能以及硬件指标之间的一部分监控数据目前是空白的，好比服务自己的负载，jvm使用，qps，tps，队列大小，等等。这些数据本不属于业务功能，可是对后续服务扩容，定位问题可以提供良好的依据。

　　天机镜的诞生就是为了解决这部分需求,咱们提供一个轻量级的数据采集接口，采集业务系统的各类指标，并将这些指标以图表的形式展现出来， 可以直观清晰的显示各个指标信息。咱们也提供了对用户所关注的指标的实时监控和报警的功能，同时还能够为用户提供定制报表的服务。

　　目前，天机镜为大数据应用的上百个监控场景提供了服务，天天收集5亿条监控数据，持久存储可达30天。然而目前仅使用四个节点做为存储，集群依然能够再增长三倍的业务量。

2. 功能设计

　　天机镜提供了图形化的查询界面，以曲线的形式呈现数据，下面是若干用例：

 

图1 Kafka集群全局负载均衡对比图（上面显示了不一样ip的字节流量）

图2. storm应用内存泄露案例（曲线名称为ip::pid，能够看出106的进程稳定，而107的进程内存到必定值后OOM，而后重启，进程号改变）

　图3. 某方法调用耗时监控（上图的点的意义是最近样本池中99.9%的调用都在0.19s如下，固然能够看平均值、p50、p7五、p9八、p99等等）

看完是否有些感受？这就是咱们平常工做中可能会关注的一些指标。在这里，咱们给这些指标取个专业点儿的名字：“维度”，也就是观测应用的某一个角度。一个应用存在多个被关注的指标，那么咱们就从多个维度出发，去对它进行监控。天机镜利用了java Metrics（一个开源的度量包https://dropwizard.github.io/metrics/3.1.0/）对监控行为作了几个分类：a. 绝对值；b.计数；c.速率；d.时间分布；e.数值结果分布；基本上任何不一样类型的度量需求都会被这五种度量类型知足。下面能够简单的列举一些例子：

　　绝对值：队列大小，Buff使用（基本上是一些size类的）

　　计数：GC次数、累计时间，出现403次数，返回错误error1的次数

　　速率：tps，qps，function1的每秒调用次数

　　时间分布：function1调用时间50%（75%，98%，99%，99.9%）都在多少秒如下，最大耗时，平均耗时

　　数值结果分布：function1的返回值50%（75%，98%，99%，99.9%）都在多少如下。

上面的这些实例性的描述，基本能够涵盖80%的需求。实际上，咱们在设计采集客户端时，就是为了知足这80%的需求。再这个前提下，保证经常使用api的default设定可以在大部分状况下适用。

数据模型与查询接口

　　数据模型的设计须要考虑功能与相应的存取效率，而查询接口就要巧妙利用模型中的数据直观多元的呈现给用户。咱们在考虑设计监控数据结构时参考了现实世界的破案现场，由于最初的设计动机就是为了快速定位系统出现的问题，实际上咱们须要的就是：（人物，时间，地点，事件），再直白一点就是：（应用，时间戳，进程惟一标识符，维度及维度大小）。你能够回过头去看上面OOM的例子。在视觉影像彻底靠脑补的日子里，咱们只能从黑白控制台中利用丑陋的命令行去查看系统日志。天机镜出现之后，咱们简单的在界面上点击几下，他就会将当时的现场回放出来。下面是存储表结构的细节：

 

appID: 应用的惟一标识
sceneID：场景ID，应用下面的惟一标识
timestamp：时间戳
location：汇报该指标所在的位置，能够是一个ip，也能够是一个ip+端口，也能够是用户自定义的一种特定标识
dimValue：具体指标名称，好比在负载场景下，具体指标就有：QPS，刷磁盘速率，Buffer大小等等
kpiValue：对应指标的值，能够是速率类型的，也能够是百分比类型的，也能够是个绝对值大小

　　查询接口很是简单，咱们须要设定一个条件：时间区间，哪些维度，哪些进程（ip or ip+pid）。另外咱们提供了多种展现方式，能够将相同的维度的不一样曲线放在一张图表（例如：负载均衡比较），也能够将一组ip的不一样维度放在一张图（消息系统流入流出的流量比较，命中与未命中数量的比较）。

 

采集客户端设计

　　采集客户端的设计决定了监控平台的易用性，使用者每每是业务开发人员，要用最小的成本换来最大的收益。因此在设计客户端时咱们从不一样的角度考虑了其易用性：

　　1. 轻量化的客户端：对于完成api层面的监控，咱们首先要将采集客户端植入应用之中，这里咱们选择在client端作轻量化的统计计算，而且开启一个静默线程每一分钟把当前的计算结果发送到后端存储，在网络不通畅的状况下，客户端感知不到异常的存在。同步监控统计结果太频繁不只会致使后端存储压力过大，也会影响用户应用的性能，更重要的是，实时需求1分钟足以。

　　2. 超简单的API：用户最但愿的是写一行代码就完成了监控工做，而现实中咱们也的确是这么作的。之因此能作到这一点，也正是由于咱们梳理出80%的需求，而另外20%个性需求才须要调用较为复杂的API，而且有些通用监控室无需设置的，好比JVM相关的各类监控。

　　因此对于监控数据的收集，咱们的定位是：归档时间长，容许丢失，近实时，统计量丰富。可能用一个词汇描述监控数据比较合适：“可视化应用日志”。

 

服务端设计

　　对于简单表结构存储大量数据的场景，Hbase是咱们的绝佳选择。为了知足天机镜的查询需求，咱们在Hbase集群上安装了Phoenix插件。Phoenix支持了类SQL语言，很容易与前端界面集成在一块儿，另外对于接收服务器，咱们简单的使用nginx+webserver的方式。对于更大的并发量，能够在接收服务器作一些batch以及throttle。接收服务器的好处还有一个就是解耦了采集端与存储层，天机镜除了支持Hbase存储以外，还支持了mysql存储。另外对于不一样的数据源，接收服务器还能够支持采集jmx监控数据。

 

 

图3 天机镜总体架构图 

　　岂止于监控，数据老是有用的。目前咱们对数据平台的基础服务层作了必定的封装，内置了不少通用指标的监控，这样咱们能够对全部平台的使用者的应用作出大体的资源占用量监控，好比消息系统的流量贡献、消费与生产消息量的核对、请求量统计、缓存命中率、数据扫描量等等。天机镜开放了数据访问接口，用户能够定制报表，平台管理员能够生成消费资源报表。另外，利用其近实时（一分钟内）的特性作短信和邮件的报警等等。

 

3. 一些结论与建议

　　整体而言，天机镜的工做是把应用的运行日志图形化展示，而且能够根据任什么时候间以多元方式对比呈现，大大化简了排查问题的难度，同时经过报表也能让咱们更直观的了解程序，预警功能避免一些问题的发生。天机镜像是一种刻画数据平台生态链各环节状态的数据引擎，固然，这须要精心设计出一个更好的交互式UI或者报表。

客户端

　　需求的梳理，最简单的api知足最大众的需求，若是想兼顾，那么必然会让api更加复杂难用；

　　不须要刻意追求数据的高实时性，增大80%的成本却提升了1%的收益这是得不偿失的；

　　既然是“可视化日志”，那么就容许丢失，同上；

　　静默，不要由于监控影响了本身的应用运行；

服务端

　　作好解耦，这样不管你由于量级升级系统，仍是由于功能升级系统都有很大的好处；

　　中间件的数据处理策略会让你的基础服务更加稳定、高效；

存储端

　　咱们在使用Hbase时遇到的最大问题在于删除数据后会致使一些IO风暴，另外在Phoenix0.4.0存在了跑死cpu的状况（0.4.2已经解决）。对于这些状况咱们的解决方案是，让表在时间上分表。换而言之就是让table像日志文件同样按照时间rolling，这样的好处是删除老数据永远都不会出现IO风暴，由于直接drop的表更当前写入的表无关。单表的数据量也会所以大大减小，查询会很是高效。但缺点就是查询时须要作一些简要的时间区间判断，在跨表查询时会十分繁琐，须要作两个sql的结果进行合并。