在7月初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分析工具