背景：
在hbase应用中，如果使用C++来访问HBase，往往通过ThriftServer进行数据的读写，ThriftServer服务的状况直接影响了应用服务的体验。因此，在HBase ThriftServer之上的Metrics系统、以及实时监控系统，可以第一时间发现服务质量变化以及相关问题，同时，良好的监控系统，也有助于服务的完善。
ThriftServer实时监控系统的挑战
1）ThriftServer的服务具有分散性。我们一般为不同的应用启动多个ThriftServer，那么如果我们想多维度统计分析某个应用的统计状况，就会比较困难。例如：百川抓取平台，随机使用多个ThriftServer进行读写操作，单个ThriftServer的实时请求状况可以很容易分析，但是如果想看整个百川平台对于HBase集群的整体压力，就必须实时地从不同的ThriftServer中收集相关读写请求的数据，然后还得将分散到不同节点上的数据，进行聚合和汇总。显然，这样工作或者可以通过中心统一的key-value store，或者通过分布式流数据处理平台。
2）报警平台采用分散式还是中心式的问题。ThriftServer是一个个体，不同的应用会把多个ThriftServer汇总在一起。那么我们如何对ThriftServer出现的问题进行报警是最有效和最健壮的，成为了设计实时监控系统需要考虑的重要问题之一。
3） 如何让监控信息可靠、并且容忍短时间错误。实时监控系统有一个特点就是，它数据是根据时间为横坐标，因此数据量较大，在整个系统中，整个系统不应该因部分Metrics没有处理，而影响到整体的监控平台的处理效果。
4）需要满足动态扩展性。因为ThriftServer依赖的HBase是动态可扩展的，那么ThriftServer监控系统也应该满足一定的扩展性，并提供足够强劲的Availability。
ThriftServer实时监控系统的架构与设计
为了更好地解决ThriftServer实时监控系统带来的挑战，该设计使用了两大特色的设计：
1）分散式报警
2）使用OpenTSDB收集实时数据。
架构图如下。
具体的设计如下：
1）每个ThriftServer都会启动一个Metrics线程，提供ReadRequestNum、WriteRequestNum、errorRequestNum的统计与汇报。具体设计思想来源于HBase Metrics和HBase Metrics的相关参数解读。这对应于上图中的实时统计信息。
2）分散式报警。分散式报警比集中报警的粒度更细，而且嵌入到每个ThriftServer中，没有中心控制平台的单点故障的问题。对于嵌入ThriftServer代码内部的不灵活性，这里利用HBase Metrics提供的配置文件，可以灵活配置相关报警的选项和Threshold。
3）中心收集平台。这里选用OpenTSDB主要考虑如下几点：
- OpenTSDB可以实现分布式部署。
- 支持tag模式，可以实现不同的统计需求
- 支持Rate、Sum、Max、Min等统计，可以实现多个ThriftServer实时收集数据的汇总。
- 提供了GnuPlot的实时绘图功能。
- 数据容器依赖于Hbase，通过AsyncHbase实现数据的异步入库。
4）随机选择OpenTSDB Server，实现一定的load balance。并且需要实时监控Telnet连接的可用性，在连接错误时，实现OpenTSDB Server的动态切换。
本系列文章属于Binos_ICT在Binospace个人技术博客原创，原文链接为http://www.binospace.com/index.php/hbase-series-3-build-thriftserver-real-time-monitoring-system/，未经允许，不得在网上转载。
相关文章：
http://www.binospace.com/index.php/hbase-combat-series-1-compression-and-coding-techniques/
http://www.binospace.com/index.php/hbase-combat-series-2-region-monitoring/
From Binospace, post HBase实战系列3—搭建ThriftServer实时监控系统
文章的脚注信息由WordPress的wp-posturl插件自动生成