OpenTSDB造成Hbase整点压力过大问题的排查和解决.docVIP

OpenTSDB造成Hbase整点压力过大问题的排查和解决 业务背景 OpenTSDB是一款非常适合存储海量时间序列数据的开源 软件，使用 HBase作为存储让它变的非常容易扩展。我们 在建设美团性能监控平台的过程中，每天需要处理数以亿计 的数据，经过几番探索和调研，最终选取了 OpenTSDB作 为数据存储层的重要组件。 OpenTSDB的安装和配置过程都 比较简单，但是在实际的业务应用中，还是会出现这样那样 的问题，本文详细介绍我们在 OpenTSDB实际使用过程中 遇到的HBase整点压力过大的问题，期望对大家有些参考 意义。 问题的出现 性能监控平台使用 OpenTSDB负责存储之后不久（创建的 表名称是tsdb-perf）,数据平台组的同事发现， tsdb-perf这 个表在最近这段时间每天上午 10点左右有大量的读操作， 造成HBase集群压力过大，但是想去分析问题的时候发现 读操作又降为 0 了，为了避免类似情况未来突然发生，需 要我来排查下原因。 于是我就想：性能监控平台目前只是个内部系统，用户使用 量不大，并且只有在用户需要查看数据时去查询，数据读取 量不应该造成 HBase的压力过大。 重现问题 如果要解决这个问题，稳定重现是个必要条件，根据数据平 台组同事的反馈，我们做了更详细的监控，每隔两分钟采集 性能监控平台所用的 HBase集群的读操作数量，发现是下 面的变化趋势： 13:00:05 13:02:01 13:04:01 13:06:02 13:08:04 13:10:02 13:12:01 13:14:02 13:16:02 13:18:02 13:20:01 13:22:01 13:24:01 13:26:01 13:28:02 13:30:01 13:32:02 0 66372 96746 仙784 99254 2814 93668 93224 90118 11376 85134 81880 80916 77694 76312 73310 0 13:34:01 0 13:36:01 0 13:38:02 0 13:40:01 0 13:42:02 0 13:44:01 0 13:46:02 0 13:48:01 0 13:50:02 0 13:52:01 0 13:54:02 0 13:56:01 0 13:58:02 0 14:00:01 0 14:02:01 36487 14:04:01 43946 14:06:01 53002 14:08:02 51598 14:10:01 54914 14:12:02 95784 14:14:04 53866 14:16:02 54868 14:18:01 54122 14:20:04 14:22:01 14:24:02 14:26:01 14:28:01 14:30:01 14:32:02 14:34:01 从图上不难看出，每到整点开始tsdb-perf这个表的读操作飓的很高，大约持续半个小时，之后恢复到 从图上不难看出，每到整点开始 tsdb-perf这个表的读操作 飓的很高，大约持续半个小时，之后恢复到 0。到下个整 点又出现类似的问题，并没有像数据平台组同事观察到的突 然回复正常了，可能他们连续两次观察的时间点刚好错开 了。 于是，真正的问题就变成了： OpenTSDB至U HBase的读操 作每到整点开始飕的很高，持续大约半小时后回复正常，这 种类脉冲式的流量冲击会给 HBase集群的稳定性带来负面 影响。 定位问题所在 事出反常必有妖，OpenTSDB至［J HBase的大量读操作肯定 伴随很大的网络流量，因为两者用 HTTP通信，我们得仔 细梳理下可能造成这种情况的几种原因。性能监控平台的架 构图如下: 从架构图可以看出，只有数据聚合服务和报表系统会和 OpenTSDB交互，聚合服务向里面写数据， 报表系统从里面 读数据。然后OpenTSDB 读数据。然后OpenTSDB负责把数据发送到 HBase中。从 数据流动的方向来讲，有可能是报表系统导致了大量的读操 作，也有可能是聚合服务里面存在不合理的读请求，也有可 能是OpenTSDB本身存在缺陷。 首先排除的是报表系统导致的大量读操作，因为只会在用户 查看某些报表时才会从 OpenTSDB读取数据，目前报表系 统每天的访问量也才几百，不足以造成如此大的影响。 其次，如何确认是否是聚合服务导致了大量的读请求呢？可 以从网络流量的视角来分析，如果聚合服务到 OpenTSDB 的流量过大，完全有可能导致 OpenTSDB至U HBase的过大 流量，但是由于目前聚合服务和 TSDB写实例是部署在相 同的机器上，无法方便的统计到网络流量的大小，于是我们 把聚合服务和 TSDB写实例分开部署，得到下