閱讀本文可以帶著下面問題：
1.HBase遇到問題，可以從幾方面解決問題？
2.HBase個別請求為什么很慢？你認為是什么原因？
3.客戶端讀寫請求為什么大量出錯？該從哪方面來分析？
4.大量服務端exception，一般原因是什么？
5.系統越來越慢的原因是什么？
6.Hbase數據寫進去，為什么會沒有了，可能的原因是什么？
7. regionserver發生abort,遇到最多是什么情況？
8.從哪些方面可以判斷HBase集群是否健康？
9.為了加強HBase的安全性，你會采取哪些措施？

在Tcon分布式系統測試實踐的分享中，筆者提到了測試人員參與線上問題分析的必要性：
1、測試工作中的問題定位提供了大量經驗，可以直接應用于線上。
2、快速的解決問題可以避免大故障的發生。
3、從線上的問題可以幫助我們準確抓住測試的重點和不足。

因此在日常的線上維護工作中，積累和很多HBase的問題分析經驗，這里于大家分享一下，如有錯誤和不足請指出。


問題分析的主要手段
1、監控系統：首先用于判斷系統各項指標是否正常，明確系統目前狀況
2、服務端日志：查看例如region移動軌跡，發生了什么動作，服務端接受處理了哪些客戶端請求。
3、gc日志：gc情況是否正常
4、操作系統日志和命令：操作系統層面、硬件是否故障，當前狀況如何
5、btrace：實時跟蹤目前服務端的請求和處理情況
6、運維工具：通過內置于系統中的功能，查看服務器實時處理狀況
其實以上手段，大部分系統都具備，不過各有各的用法，下面我會通過常見的問題來梳理這6大手段。

常見問題1：個別請求為什么很慢？
個別請求慢是用戶遇到最多的問題，首先需要明確是客戶端還是服務端原因，進而分析服務端狀況以及捕獲這些請求來明確定位。
1、通過客戶端日志來初步分析下慢請求的規律，嘗試在客戶端確定請求的rowkey和操作類型。
2、確定是不是一段時間內集中出現慢請求，如果是那么可以參考常見問題2來解決。
3、查看服務端監控，觀察響應時間是否平穩，maxResponseTime是否出現峰值。如果存在，那么可以初步確定是服務端問題。
4、客戶端分析無效，可以通過運維工具在服務端捕獲慢請求的rowkey和操作類型。
5、確定rowkey對應的region，初步查看是否存在數據表參數配置不合理（例如version設置過多、blockcache、bloomfilter類型不正確）、storefile過多、命中率過低等問題。
6、嘗試重試這些請求或者直接分析hfile來查看返回結果是否過大，請求是否耗費資源過多。
7、查看服務端關于hdfs的監控和日志，以及datanode日志，來分析是否存在hdfs塊讀取慢或者磁盤故障。

常見問題2：客戶端讀寫請求為什么大量出錯？
讀寫請求大量出錯的現象主要有兩類：1、大量出現服務端exception 2、大量超時。其中第一種有異常信息較好判斷問題所在。
1、大量服務端exception一般是region不在線導致的，可能是region在split但是時間很長超過預期，或是meta數據錯誤導致客戶端獲取region location錯誤。以上現象均可通過日志來定位。
2、遇到大量超時，首先應該排除服務端是否出現了fullgc或者ygc時間過長。前者可能由于內存碎片、cms gc速度來不及導致，后者一般是由于系統使用了swap內存。
3、通過系統命令和日志來查看是否有機器load過高，磁盤壓力過大，磁盤故障。
4、查看監控是否出現callqueue積壓，請求無法得到及時處理，進一步通過call查看工具或者jstack可以查看正在處理的call和進程堆棧信息。
5、通過datanode日志和hbase訪問dfs的時間，來判斷問題是否在hdfs層。
6、查看監控判斷是否出現blocking update，memstore是否已接近系統設置的上限。

常見問題3：系統為什么越來越慢了？
系統原來挺快的，為什么越來越慢？多數是不合理的服務端配置導致的，可以通過以下幾個方面來分析。
1、磁盤讀寫和系統load是不是比以前高了，初步判斷導致系統變慢的原因。
2、如果磁盤讀寫加劇，重點查看flush是否過小，compact是否過頻，尤其是major compact是否有必要，從測試結果來看compact產生的磁盤io對系統性能影響很大。
3、單個region的storefile個數是否有成倍提高
4、命中率是否有下降趨勢
5、regionserver是否存在region分配不均衡導致的讀寫集中，或者讀寫handler的競爭
6、datablock的本地化率是否出現下降
7、是否存在datanode運行不正常，可以通過監控查看是否有個別機器讀取block時間明顯偏高

常見問題4：數據為什么沒了，明明寫進去過？
數據丟失也是HBase的常見bug，分為臨時性和永久性兩類。臨時性的丟失往往是由于hbase本身的正確性問題導致瞬間讀取數據錯誤。永久性丟失一般是日志恢復bug或者region的二次分配。
1、首先可以通過hbck或者master日志排查丟失的數據所在region是否發生過二次分配
2、集群中的regionserver是否出現過abort，日志是否正確恢復。
3、掃描storefile確定目前數據情況
4、掃描logs或者oldlogs中的文件來確定是否寫入過這些數據，以及寫入數據的時間，配合rs的日志來確定當時server的行為
5、根據寫入數據的時間，確定regionserver是否正確完成了flush并且將數據寫入磁盤

常見問題5：為什么有服務器進程掛了？
regionserver發生abort的場景很多，除了系統bug引起的以外，線上遇到最多的就是fullgc引起的zk節點超時和文件系統異常。
1、查看regionserver日志查詢FATAL異常，確定異常類型
2、查看gc日志確定是否發生fullgc或者ygc時間過長
3、如果沒有征兆，日志突然中斷，首先需要考慮是否發生了OOM（0.94版本會直接kill -9）。
4、可以通過系統內存監控判斷是否出現被占滿的情況
5、查看datanode是否出現異常日志，regionserver可能由于roll log或者flush時的文件系統異常導致abort
6、排除人為調用stop的情況

HBase健康體檢
一個集群似乎否健康，大體可以從以下幾個方面來判斷
1、單region的storefile數量是否合理
2、memstore是否得到合理的利用，此項指標與hlog的數量和大小相關
3、compact和flush的流量比值是否合理，如果每天僅flush 1G卻要compact幾十上百G就是明顯的浪費
4、split似乎否過頻，能否采取pre-sharding的方式來預分配region
5、集群的region是否過多，zk在默認參數下無法支撐12w以上的region個數，并且region過多也會影響regionserver failover的時間
6、讀寫相應時間是否合理，datablock的讀取延時是否符合預期
7、flush隊列、callqueue長度、compact隊列是否符合預期。前兩者的積壓都會造成系統不穩定。
8、failedRequest和maxResponseTime
9、gc狀況，過長的ygc和過頻的cms都需要警惕

運維工具
HBase官方版本的可運維性的確很差，為了能最大限度的保證線上系統安全，快速定位故障原因，阿里做了很多建設性的工作。
1、建立了完整的監控體系，根據日常測試和線上運行經驗，加入了很多監控點。
2、監控的粒度達到region級別
3、call dump和線上慢請求追蹤功能
4、btrace腳本體系，出現問題直接運行查看程序內部信息
5、日志收集和報警
6、在線表維護工具和storefile、logs分析工具

轉載于:https://www.cnblogs.com/dhName/p/10790600.html

總結

以上是生活随笔為你收集整理的hbase 问题整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。