在数据量越来越大时，如何绕过logstash、实时流处理jstorm和OPENTSDB的那些坑(1)

先介绍一下我们公司的大数据基本架构。我们公司的架构为beats负责采集原始节点数据，kafka负责数据队列的管理，数据实时流处理用的是阿里的开源jstorm，通过jstorm处理后，文本类型的日志将进入elasticsearch，数值型的指标数据将进入时序数据库opentsdb。在实际的运行过程中，伴随着数据量越来越大，各个环节都曾出现过瓶颈与资源不足的情况。自己写个小专栏，记录自己当大数据工程师的这些经历吧。

先介绍一次opentsdb出现的问题吧：监控程序报警，说opentsdb取数大面积失败，这可非同小可，因为opentsdb的数据读取与展示关系着大数据团队的形象，可不能让它自动打脸。我进行了如下所示的一系列操作：

1.要想看opentsdb是否出问题，先得看HBASE是否正常。我们使用的是开源的cloudera Hadoop，CM界面还是比较友好的。看了一下我们的hbase，提示健康度为good health；日志里面显示的唯一隐患，也已经是好多天前的事情了。真正值得关注的是读写请求，读请求曲线平稳，写请求的量在一小时前开始明显下降。我们再使用grafana进行opentsdb的查看，发现一小时前是有数据的，而且数据也在缓慢地更新，但是每写入一分钟的数据，要花去两三分钟，就是这个原因导致opentsdb没有实时数据出来。

2.查看了opentsdb的原生界面，毫无收获，搜索到一条error级别的日志都没有，sigh。

3.有缘千里来相会，需往西湖高处寻。写入opentsdb的数据流处理是jstorm的一个topology。查了一下jstorm的界面，完全都是好好的，两个bolt的连线也都正常。查日志，一条error日志也都没有。苦思冥想，不知道出了什么问题。

往往在苦思冥想不成功时，最适合的方法是出去洗把脸、思考最近系统最近出了什么变化，对大数据而言就是增加了哪些数据和读写操作。果然，最近确实有某展示应用增加了不少写入opentsdb的指标，并且读写操作也非常频繁，给opentsdb估计造成了不小的压力。那么最好的办法，就是迁移opentsdb，把这部分http连接的压力转移出去。

说干就干。前台的展示应用需要不停访问webserver，webserver又要访问opentsdb进行数据读取，那么我们就在Hadoop集群中另找了一台有tomcat进程的机器，拷贝了原有的webserver过去这个节点；下一步把opentsdb也进行了相应的迁移。最后一步，把前台应用的访问网址配置文件，修改成新的webserver，webserver的访问ip也修改成新的opentsdb。这样就把http连接给转移出去了。

再次查看前台展示应用，依然无数据，orz。

无奈之下，权衡了一下利弊，不得不把jstorm的写入opentsdb的topology进行重启。终于，全部恢复，前台展示应用也全部显示正常，CDH的写数据曲线也是直接拉升回到了正常高度。但是，重启大法有风险，一旦opentsdb中丢了重要数据，要再从hdfs里面再次生成指标、捞回来，回家就估计太晚了，该挨媳妇骂了。所以，要慎用。

好了，第一次的心路历程就分享到这里。等下次有时间，再分享大数据路上的点点滴滴。