在資料量越來越大時，如何繞過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裡面再次生成名額、撈回來，回家就估計太晚了，該挨媳婦罵了。是以，要慎用。

好了，第一次的心路曆程就分享到這裡。等下次有時間，再分享大資料路上的點點滴滴。