ホームページ >データベース >mysql チュートリアル >HBase实战系列3—搭建ThriftServer实时监控系统
背景: 在hbase应用中,如果使用C++来访问HBase,往往通过ThriftServer进行数据的读写,ThriftServer服务的状况直接影响了应用服务的体验。因此,在HBase ThriftServer之上的Metrics系统、以及实时监控系统,可以第一时间发现服务质量变化以及相关问题,同时
在hbase应用中,如果使用C++来访问HBase,往往通过ThriftServer进行数据的读写,ThriftServer服务的状况直接影响了应用服务的体验。因此,在HBase ThriftServer之上的Metrics系统、以及实时监控系统,可以第一时间发现服务质量变化以及相关问题,同时,良好的监控系统,也有助于服务的完善。
1)ThriftServer的服务具有分散性。我们一般为不同的应用启动多个ThriftServer,那么如果我们想多维度统计分析某个应用的统计状况,就会比较困难。例如:百川抓取平台,随机使用多个ThriftServer进行读写操作,单个ThriftServer的实时请求状况可以很容易分析,但是如果想看整个百川平台对于HBase集群的整体压力,就必须实时地从不同的ThriftServer中收集相关读写请求的数据,然后还得将分散到不同节点上的数据,进行聚合和汇总。显然,这样工作或者可以通过中心统一的key-value store,或者通过分布式流数据处理平台。
2)报警平台采用分散式还是中心式的问题。ThriftServer是一个个体,不同的应用会把多个ThriftServer汇总在一起。那么我们如何对ThriftServer出现的问题进行报警是最有效和最健壮的,成为了设计实时监控系统需要考虑的重要问题之一。
3)?如何让监控信息可靠、并且容忍短时间错误。实时监控系统有一个特点就是,它数据是根据时间为横坐标,因此数据量较大,在整个系统中,整个系统不应该因部分Metrics没有处理,而影响到整体的监控平台的处理效果。
4)需要满足动态扩展性。因为ThriftServer依赖的HBase是动态可扩展的,那么ThriftServer监控系统也应该满足一定的扩展性,并提供足够强劲的Availability。
为了更好地解决ThriftServer实时监控系统带来的挑战,该设计使用了两大特色的设计:
1)分散式报警
2)使用OpenTSDB收集实时数据。
架构图如下。
具体的设计如下:
1)每个ThriftServer都会启动一个Metrics线程,提供ReadRequestNum、WriteRequestNum、errorRequestNum的统计与汇报。具体设计思想来源于HBase Metrics和HBase Metrics的相关参数解读。这对应于上图中的实时统计信息。
2)分散式报警。分散式报警比集中报警的粒度更细,而且嵌入到每个ThriftServer中,没有中心控制平台的单点故障的问题。对于嵌入ThriftServer代码内部的不灵活性,这里利用HBase Metrics提供的配置文件,可以灵活配置相关报警的选项和Threshold。
3)中心收集平台。这里选用OpenTSDB主要考虑如下几点:
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插件自动生成