opentsdb造成hbase整点压力过大问题的排查和解决

opentsdb造成hbase整点压力过大问题的排查和解决

ID:27667182

大小:132.92 KB

页数:17页

时间:2018-12-05

opentsdb造成hbase整点压力过大问题的排查和解决_第1页
opentsdb造成hbase整点压力过大问题的排查和解决_第2页
opentsdb造成hbase整点压力过大问题的排查和解决_第3页
opentsdb造成hbase整点压力过大问题的排查和解决_第4页
opentsdb造成hbase整点压力过大问题的排查和解决_第5页
资源描述:

《opentsdb造成hbase整点压力过大问题的排查和解决》由会员上传分享,免费在线阅读,更多相关内容在学术论文-天天文库

1、个表在最近这段时间每天上午10点左右有大量的读操作,OpenTSDB造成Hbase整点压力过大问题的排查和解决业务背景OpenTSDB是一款非常适合存储海量时间序列数据的开源软件,使用HBase作为存储让它变的非常容易扩展。我们在建设美团性能监控平台的过程中,每天需要处理数以亿计的数据,经过几番探索和调研,最终选取了OpenTSDB作为数据存储层的重要组件。OpenTSDB的安装和配置过程都比较简单,但是在实际的业务应用中,还是会出现这样那样的问题,本文详细介绍我们在OpenTSDB实际使用过程中遇到的HBase整点压力过大的问题,期望对大家有些参考意义。问题的出现性能监控平台使

2、用OpenTSDB负责存储之后不久(创建的tsdb-perf这表名称是tsdb-perf),数据平台组的同事发现,造成HBase集群压力过大,但是想去分析问题的时候发现读操作又降为0了,为了避免类似情况未来突然发生,需要我来排查下原因。于是我就想:性能监控平台目前只是个内部系统,用户使用量不大,并且只有在用户需要查看数据时去查询,数据读取量不应该造成HBase的压力过大。重现问题如果要解决这个问题,稳定重现是个必要条件,根据数据平台组同事的反馈,我们做了更详细的监控,每隔两分钟采集性能监控平台所用的HBase集群的读操作数量,发现是下面的变化趋势:13:00:05013:02:0

3、16637213:04:019674613:06:0210178413:08:019925413:10:02281413:12:019366813:14:0213:16:02932249011813:18:021137613:20:018513413:22:018188013:24:018091613:26:017769413:28:027631213:30:017331013:32:02013:34:01013:36:01013:38:02013:40:01013:42:02013:44:01013:46:02013:48:01013:50:02013:52:01013:54:

4、02013:56:01013:58:02014:00:01014:02:013648714:04:014394614:06:015300214:08:025159814:10:015491414:12:029578414:14:045386614:16:025486814:18:015412214:20:0414:22:0114:24:0214:26:0114:28:0114:30:0114:32:0214:34:01从图上不难看出,每到整点开始tsdb-perf这个表的读操作飚的很高,大约持续半个小时,之后恢复到0。到下个整点又出现类似的问题,并没有像数据平台组同事观察到的突然

5、回复正常了,可能他们连续两次观察的时间点刚好错开了。于是,真正的问题就变成了:OpenTSDB到HBase的读操作每到整点开始飚的很高,持续大约半小时后回复正常,这种类脉冲式的流量冲击会给HBase集群的稳定性带来负面影响。定位问题所在事出反常必有妖,OpenTSDB到HBase的大量读操作肯定伴随很大的网络流量,因为两者用HTTP通信,我们得仔细梳理下可能造成这种情况的几种原因。性能监控平台的架构图如下:从架构图可以看出,只有数据聚合服务和报表系统会和OpenTSDB交互,聚合服务向里面写数据,报表系统从里面读数据。然后OpenTSDB负责把数据发送到HBase中。从数据流动的

6、方向来讲,有可能是报表系统导致了大量的读操作,也有可能是聚合服务里面存在不合理的读请求,也有可能是OpenTSDB本身存在缺陷。首先排除的是报表系统导致的大量读操作,因为只会在用户查看某些报表时才会从OpenTSDB读取数据,目前报表系统每天的访问量也才几百,不足以造成如此大的影响。其次,如何确认是否是聚合服务导致了大量的读请求呢?可以从网络流量的视角来分析,如果聚合服务到OpenTSDB的流量过大,完全有可能导致OpenTSDB到HBase的过大流量,但是由于目前聚合服务和TSDB写实例是部署在相同的机器上,无法方便的统计到网络流量的大小,于是我们把聚合服务和TSDB写实例分开

7、部署,得到下面的流量统计图:聚合服务只接收来自解析服务的数据包计算完毕之后发送给TSDB,其网络流量如下图:TSDB服务只接收来自聚合服务的数据,然后发送到HBase,却出现了脉冲式的冲高回落,网络流量如下图.•这样,就可以排除聚合服务造成的问题,出问题的地方就在OpenTSDB和HBase集群之间,其他业务线并没有造成HBase的压力过大,看来问题应该出在OpenTSDB里面,如果这个问题是OpenTSDB内部存在的,那么其他使用了OpenTSDB的系统肯定也存在类似的问题,下

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。