不管是作为运维还是开发，在排查故障或者进行性能调优的时候，监控都是必不可少的。一般我们讲监控，其实包括了metric监控和日志监控。这篇文章主要分享如何利用开源搭建HBase 的metric监控系统，而日志在初期可能没有那么重要，或者后期可以通过elk来实现。
经过调研，大概有以下几种方案：
1. 实现[gmetad](<a>https://github.com/ganglia/monitor-core/tree/master/gmetad-python)的python插件，从gmond收集数据之后写opentsdb，报警可以采用bosun</a>
2. 直接采用[prometheus](<a>https://prometheus.io/)整个系统，利用jmx_exporter，使用javaagent的方式启动收集，报警采用自带alterManager
3. 实现Sink发送到 [pushgateway](<a>https://github.com/prometheus/pushgateway)或者opentsdb，报警跟1，2</a>类似
4. 利用hadoop的metric自己的GraphiteSink发送到influxDB-graphite
5. 直接利用[TCollecotr](<a>http://opentsdb.net/docs/build/html/user_guide/utilities/tcollector.html)收集，发送到opentsdb</a>
方案的对比
第1，2方案采用是pull，或者pull + push的方式。
在第1种方案中，metric的解析（例如region的metric）需要在插件里面实现，第2种方案的jmx解析可以通过配置正则解析。在部署方面：第1种方案需要独立部署和维护gmond，第2种方案采用java的agent技术，类似拦截器可以在HBase进程启动的时候注册。在报警上：第1种方式由于自己解析相对比较灵活，例如可以把需要监控数据以一定的格式写到公司内部的监控系统或者采用开源的bosun（一个基于opentsdb和redis的监控报警系统）；第2种方式可以采用本身自带的监控系统。
第3，4方案采用是利用Hadoop本身的metric系统，通过改写Sink或者增加新的Sink系统实现监控信息的吐出。pushgateway是prometheus提供的类似中转站的实现，可以接收数据的push。第四种是因为influxdb兼容graphite的接口，所以可以吐到graphite。但是经过测试，发现influxdb的graphite提供的解析jmx存在无法解析特殊字符的问题，例如“Context=regionserver.Hostname=gdc-dn05-devbase.i.nease.net“ 的解析目前来说比较恶心，所以如果有好的方案，也欢迎跟留言交流。
第5种方案，采用push的方式，通过在每个服务上部署TCollector程序，收集jmx信息，发送到opentsdb，所以需要部署和管理TCollector。之前在在上家公司采用的是改写TCollector发送到celery然后写入到opentsdb中的方式。
存储上，opentsdb的底层是HBase，所以可以横向扩张；但是opentsdb读取也一直为人诟病，虽然说在未来版本也会加入redis缓存一个小时内的数据，但是目前还没有发布。而相比而言，prometheus的目前采用的单机存储，所以取决于盘大小。看了一些官方计划，也准备支持远程读写，例如opentsdb，但是目前opentsdb和influxdb还不支持float64，详细[Remote storage](<a>https://github.com/prometheus/prometheus/issues/10)，其实最好就是在提供本地保存3个月数据，然后全量存储在opentsdb方案。官方公布的消息The</a> current record is 800k samples/s, which is enough to monitor over 10k node exporters at a 10s interval。
在查询上性能上目前还没有数据量上的测试，从小数据量来说，基本差不多。查询语言上来说，promethues会更丰富一些，例如可以两个指标之间加减，不过目前我们需要的基本信息也没有必要用到那么复杂的查询。在客户端兼容性方面，目前promethues提供的jmx_exporter可以满足绝大多数的监控需要，TCollector的收集也能收集大多数的hadoop体系的jmx信息。
方案的选择
最终，我采用从gmond读取数据的方式，原因有两个，一个是自己写插件的话可以控制写到任何一个地方和修改逻辑，会比较自由；另外一个就是hadoop生态的体系的组件都支持发送到gmond。根据测试采用python的插件，性能没有办法满足我们目前的规模，主要原因是python的多线程是跑一个cpu。所以我用java实现了类似功能，只要实现读取gmond放到内存队列，起多个线程消费写到opentsdb和其他地方。由于代码写的一般，所以没有放到githup 上，有需要参考的同学可以跟我联系。目前在抓取和写入上没有瓶颈，查看HBase的ops大概是20万次左右。当然，这里存在单点问题。
网友评论