HBase工程師線上工做經驗總結----HBase常見問題及分析

閱讀本文能夠帶着下面問題：
1.HBase遇到問題，能夠從幾方面解決問題？
2.HBase個別請求爲何很慢？你認爲是什麼緣由？
3.客戶端讀寫請求爲何大量出錯？該從哪方面來分析？
4.大量服務端exception，通常緣由是什麼？
5.系統愈來愈慢的緣由是什麼？
6.Hbase數據寫進去，爲何會沒有了，可能的緣由是什麼？
7. regionserver發生abort,遇到最可能是什麼狀況？
8.從哪些方面能夠判斷HBase集羣是否健康？
9.爲了增強HBase的安全性，你會採起哪些措施？

在Tcon分佈式系統測試實踐的分享中，筆者提到了測試人員參與線上問題分析的必要性：
一、測試工做中的問題定位提供了大量經驗，能夠直接應用於線上。
二、快速的解決問題能夠避免大故障的發生。
三、從線上的問題能夠幫助咱們準確抓住測試的重點和不足。

所以在平常的線上維護工做中，積累和不少HBase的問題分析經驗，這裏於你們分享一下，若有錯誤和不足請指出。


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

常見問題1：個別請求爲何很慢？
個別請求慢是用戶遇到最多的問題，首先須要明確是客戶端仍是服務端緣由，進而分析服務端情況以及捕獲這些請求來明肯定位。
一、經過客戶端日誌來初步分析下慢請求的規律，嘗試在客戶端肯定請求的rowkey和操做類型。
二、肯定是否是一段時間內集中出現慢請求，若是是那麼能夠參考常見問題2來解決。
三、查看服務端監控，觀察響應時間是否平穩，maxResponseTime是否出現峯值。若是存在，那麼能夠初步肯定是服務端問題。
四、客戶端分析無效，能夠經過運維工具在服務端捕獲慢請求的rowkey和操做類型。
五、肯定rowkey對應的region，初步查看是否存在數據表參數配置不合理（例如version設置過多、blockcache、bloomfilter類型不正確）、storefile過多、命中率太低等問題。
六、嘗試重試這些請求或者直接分析hfile來查看返回結果是否過大，請求是否耗費資源過多。
七、查看服務端關於hdfs的監控和日誌，以及datanode日誌，來分析是否存在hdfs塊讀取慢或者磁盤故障。

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

常見問題3：系統爲何愈來愈慢了？
系統原來挺快的，爲何愈來愈慢？多數是不合理的服務端配置致使的，能夠經過如下幾個方面來分析。
一、磁盤讀寫和系統load是否是比之前高了，初步判斷致使系統變慢的緣由。
二、若是磁盤讀寫加重，重點查看flush是否太小，compact是否過頻，尤爲是major compact是否有必要，從測試結果來看compact產生的磁盤io對系統性能影響很大。
三、單個region的storefile個數是否有成倍提升
四、命中率是否有降低趨勢
五、regionserver是否存在region分配不均衡致使的讀寫集中，或者讀寫handler的競爭
六、datablock的本地化率是否出現降低
七、是否存在datanode運行不正常，能夠經過監控查看是否有個別機器讀取block時間明顯偏高

常見問題4：數據爲何沒了，明明寫進去過？
數據丟失也是HBase的常見bug，分爲臨時性和永久性兩類。臨時性的丟失每每是因爲hbase自己的正確性問題致使瞬間讀取數據錯誤。永久性丟失通常是日誌恢復bug或者region的二次分配。
一、首先能夠經過hbck或者master日誌排查丟失的數據所在region是否發生過二次分配
二、集羣中的regionserver是否出現過abort，日誌是否正確恢復。
三、掃描storefile肯定目前數據狀況
四、掃描logs或者oldlogs中的文件來肯定是否寫入過這些數據，以及寫入數據的時間，配合rs的日誌來肯定當時server的行爲
五、根據寫入數據的時間，肯定regionserver是否正確完成了flush而且將數據寫入磁盤

常見問題5：爲何有服務器進程掛了？
regionserver發生abort的場景不少，除了系統bug引發的之外，線上遇到最多的就是fullgc引發的zk節點超時和文件系統異常。
一、查看regionserver日誌查詢FATAL異常，肯定異常類型
二、查看gc日誌肯定是否發生fullgc或者ygc時間過長
三、若是沒有徵兆，日誌忽然中斷，首先須要考慮是否發生了OOM（0.94版本會直接kill -9）。
四、能夠經過系統內存監控判斷是否出現被佔滿的狀況
五、查看datanode是否出現異常日誌，regionserver可能因爲roll log或者flush時的文件系統異常致使abort
六、排除人爲調用stop的狀況

HBase健康體檢
一個集羣彷佛否健康，大致能夠從如下幾個方面來判斷
一、單region的storefile數量是否合理
二、memstore是否獲得合理的利用，此項指標與hlog的數量和大小相關
三、compact和flush的流量比值是否合理，若是天天僅flush 1G卻要compact幾十上百G就是明顯的浪費
四、split彷佛否過頻，可否採起pre-sharding的方式來預分配region
五、集羣的region是否過多，zk在默認參數下沒法支撐12w以上的region個數，而且region過多也會影響regionserver failover的時間
六、讀寫相應時間是否合理，datablock的讀取延時是否符合預期
七、flush隊列、callqueue長度、compact隊列是否符合預期。前二者的積壓都會形成系統不穩定。
八、failedRequest和maxResponseTime
九、gc情況，過長的ygc和過頻的cms都須要警戒

運維工具
HBase官方版本的可運維性的確不好，爲了能最大限度的保證線上系統安全，快速定位故障緣由，阿里作了不少建設性的工做。
一、創建了完整的監控體系，根據平常測試和線上運行經驗，加入了不少監控點。
二、監控的粒度達到region級別
三、call dump和線上慢請求追蹤功能
四、btrace腳本體系，出現問題直接運行查看程序內部信息
五、日誌收集和報警
六、在線表維護工具和storefile、logs分析工具