閱讀本文可以帶著下面問(wèn)題：1.HBase遇到問(wèn)題，可以從幾方面解決問(wèn)題？2.HBase個(gè)別請(qǐng)求為什么很慢？你認(rèn)為是什么原因？3.客戶端讀寫(xiě)請(qǐng)求為什么大量出錯(cuò)？該從哪方面來(lái)分析？4.大量服務(wù)端exception，一般原因是什么？5.系統(tǒng)越來(lái)越慢的原因是什么？6.Hbase數(shù)據(jù)寫(xiě)進(jìn)去，為什么會(huì)沒(méi)有了，可能的原因是什么？7. regionserver發(fā)生abort,遇到最多是什么情況？8.從哪些方面可以判斷HBase集群是否健康？9.為了加強(qiáng)HBase的安全性，你會(huì)采取哪些措施？在Tcon分布式系統(tǒng)測(cè)試實(shí)踐的分享中，筆者提到了測(cè)試人員參與線上問(wèn)題分析的必要性：
1、測(cè)試工作中的問(wèn)題定位提供了大量經(jīng)驗(yàn)，可以直接應(yīng)用于線上。
2、快速的解決問(wèn)題可以避免大故障的發(fā)生。
3、從線上的問(wèn)題可以幫助我們準(zhǔn)確抓住測(cè)試的重點(diǎn)和不足。
因此在日常的線上維護(hù)工作中，積累和很多HBase的問(wèn)題分析經(jīng)驗(yàn)，這里于大家分享一下，如有錯(cuò)誤和不足請(qǐng)指出。
問(wèn)題分析的主要手段1、監(jiān)控系統(tǒng)：首先用于判斷系統(tǒng)各項(xiàng)指標(biāo)是否正常，明確系統(tǒng)目前狀況
2、服務(wù)端日志：查看例如region移動(dòng)軌跡，發(fā)生了什么動(dòng)作，服務(wù)端接受處理了哪些客戶端請(qǐng)求。
3、gc日志：gc情況是否正常
4、操作系統(tǒng)日志和命令：操作系統(tǒng)層面、硬件是否故障，當(dāng)前狀況如何
5、btrace：實(shí)時(shí)跟蹤目前服務(wù)端的請(qǐng)求和處理情況
6、運(yùn)維工具：通過(guò)內(nèi)置于系統(tǒng)中的功能，查看服務(wù)器實(shí)時(shí)處理狀況
其實(shí)以上手段，大部分系統(tǒng)都具備，不過(guò)各有各的用法，下面我會(huì)通過(guò)常見(jiàn)的問(wèn)題來(lái)梳理這6大手段。
常見(jiàn)問(wèn)題1：個(gè)別請(qǐng)求為什么很慢？個(gè)別請(qǐng)求慢是用戶遇到最多的問(wèn)題，首先需要明確是客戶端還是服務(wù)端原因，進(jìn)而分析服務(wù)端狀況以及捕獲這些請(qǐng)求來(lái)明確定位。
1、通過(guò)客戶端日志來(lái)初步分析下慢請(qǐng)求的規(guī)律，嘗試在客戶端確定請(qǐng)求的rowkey和操作類型。
2、確定是不是一段時(shí)間內(nèi)集中出現(xiàn)慢請(qǐng)求，如果是那么可以參考常見(jiàn)問(wèn)題2來(lái)解決。
3、查看服務(wù)端監(jiān)控，觀察響應(yīng)時(shí)間是否平穩(wěn)，maxResponseTime是否出現(xiàn)峰值。如果存在，那么可以初步確定是服務(wù)端問(wèn)題。
4、客戶端分析無(wú)效，可以通過(guò)運(yùn)維工具在服務(wù)端捕獲慢請(qǐng)求的rowkey和操作類型。
5、確定rowkey對(duì)應(yīng)的region，初步查看是否存在數(shù)據(jù)表參數(shù)配置不合理（例如version設(shè)置過(guò)多、blockcache、bloomfilter類型不正確）、storefile過(guò)多、命中率過(guò)低等問(wèn)題。
6、嘗試重試這些請(qǐng)求或者直接分析hfile來(lái)查看返回結(jié)果是否過(guò)大，請(qǐng)求是否耗費(fèi)資源過(guò)多。
7、查看服務(wù)端關(guān)于hdfs的監(jiān)控和日志，以及datanode日志，來(lái)分析是否存在hdfs塊讀取慢或者磁盤(pán)故障。
常見(jiàn)問(wèn)題2：客戶端讀寫(xiě)請(qǐng)求為什么大量出錯(cuò)？讀寫(xiě)請(qǐng)求大量出錯(cuò)的現(xiàn)象主要有兩類：1、大量出現(xiàn)服務(wù)端exception 2、大量超時(shí)。其中第一種有異常信息較好判斷問(wèn)題所在。
1、大量服務(wù)端exception一般是region不在線導(dǎo)致的，可能是region在split但是時(shí)間很長(zhǎng)超過(guò)預(yù)期，或是meta數(shù)據(jù)錯(cuò)誤導(dǎo)致客戶端獲取region location錯(cuò)誤。以上現(xiàn)象均可通過(guò)日志來(lái)定位。
2、遇到大量超時(shí)，首先應(yīng)該排除服務(wù)端是否出現(xiàn)了fullgc或者ygc時(shí)間過(guò)長(zhǎng)。前者可能由于內(nèi)存碎片、cms gc速度來(lái)不及導(dǎo)致，后者一般是由于系統(tǒng)使用了swap內(nèi)存。
3、通過(guò)系統(tǒng)命令和日志來(lái)查看是否有機(jī)器load過(guò)高，磁盤(pán)壓力過(guò)大，磁盤(pán)故障。
4、查看監(jiān)控是否出現(xiàn)callqueue積壓，請(qǐng)求無(wú)法得到及時(shí)處理，進(jìn)一步通過(guò)call查看工具或者jstack可以查看正在處理的call和進(jìn)程堆棧信息。
5、通過(guò)datanode日志和hbase訪問(wèn)dfs的時(shí)間，來(lái)判斷問(wèn)題是否在hdfs層。
6、查看監(jiān)控判斷是否出現(xiàn)blocking update，memstore是否已接近系統(tǒng)設(shè)置的上限。
常見(jiàn)問(wèn)題3：系統(tǒng)為什么越來(lái)越慢了？系統(tǒng)原來(lái)挺快的，為什么越來(lái)越慢？多數(shù)是不合理的服務(wù)端配置導(dǎo)致的，可以通過(guò)以下幾個(gè)方面來(lái)分析。
1、磁盤(pán)讀寫(xiě)和系統(tǒng)load是不是比以前高了，初步判斷導(dǎo)致系統(tǒng)變慢的原因。
2、如果磁盤(pán)讀寫(xiě)加劇，重點(diǎn)查看flush是否過(guò)小，compact是否過(guò)頻，尤其是major compact是否有必要，從測(cè)試結(jié)果來(lái)看compact產(chǎn)生的磁盤(pán)io對(duì)系統(tǒng)性能影響很大。
3、單個(gè)region的storefile個(gè)數(shù)是否有成倍提高
4、命中率是否有下降趨勢(shì)
5、regionserver是否存在region分配不均衡導(dǎo)致的讀寫(xiě)集中，或者讀寫(xiě)handler的競(jìng)爭(zhēng)
6、datablock的本地化率是否出現(xiàn)下降
7、是否存在datanode運(yùn)行不正常，可以通過(guò)監(jiān)控查看是否有個(gè)別機(jī)器讀取block時(shí)間明顯偏高
常見(jiàn)問(wèn)題4：數(shù)據(jù)為什么沒(méi)了，明明寫(xiě)進(jìn)去過(guò)？數(shù)據(jù)丟失也是HBase的常見(jiàn)bug，分為臨時(shí)性和永久性兩類。臨時(shí)性的丟失往往是由于hbase本身的正確性問(wèn)題導(dǎo)致瞬間讀取數(shù)據(jù)錯(cuò)誤。永久性丟失一般是日志恢復(fù)bug或者region的二次分配。
1、首先可以通過(guò)hbck或者master日志排查丟失的數(shù)據(jù)所在region是否發(fā)生過(guò)二次分配
2、集群中的regionserver是否出現(xiàn)過(guò)abort，日志是否正確恢復(fù)。
3、掃描storefile確定目前數(shù)據(jù)情況
4、掃描logs或者oldlogs中的文件來(lái)確定是否寫(xiě)入過(guò)這些數(shù)據(jù)，以及寫(xiě)入數(shù)據(jù)的時(shí)間，配合rs的日志來(lái)確定當(dāng)時(shí)server的行為
5、根據(jù)寫(xiě)入數(shù)據(jù)的時(shí)間，確定regionserver是否正確完成了flush并且將數(shù)據(jù)寫(xiě)入磁盤(pán)
常見(jiàn)問(wèn)題5：為什么有服務(wù)器進(jìn)程掛了？ regionserver發(fā)生abort的場(chǎng)景很多，除了系統(tǒng)bug引起的以外，線上遇到最多的就是fullgc引起的zk節(jié)點(diǎn)超時(shí)和文件系統(tǒng)異常。
1、查看regionserver日志查詢FATAL異常，確定異常類型
2、查看gc日志確定是否發(fā)生fullgc或者ygc時(shí)間過(guò)長(zhǎng)
3、如果沒(méi)有征兆，日志突然中斷，首先需要考慮是否發(fā)生了OOM（0.94版本會(huì)直接kill -9）。
4、可以通過(guò)系統(tǒng)內(nèi)存監(jiān)控判斷是否出現(xiàn)被占滿的情況
5、查看datanode是否出現(xiàn)異常日志，regionserver可能由于roll log或者flush時(shí)的文件系統(tǒng)異常導(dǎo)致abort
6、排除人為調(diào)用stop的情況
HBase健康體檢一個(gè)集群似乎否健康，大體可以從以下幾個(gè)方面來(lái)判斷
1、單region的storefile數(shù)量是否合理
2、memstore是否得到合理的利用，此項(xiàng)指標(biāo)與hlog的數(shù)量和大小相關(guān)
3、compact和flush的流量比值是否合理，如果每天僅flush 1G卻要compact幾十上百G就是明顯的浪費(fèi)
4、split似乎否過(guò)頻，能否采取pre-sharding的方式來(lái)預(yù)分配region
5、集群的region是否過(guò)多，zk在默認(rèn)參數(shù)下無(wú)法支撐12w以上的region個(gè)數(shù)，并且region過(guò)多也會(huì)影響regionserver failover的時(shí)間
6、讀寫(xiě)相應(yīng)時(shí)間是否合理，datablock的讀取延時(shí)是否符合預(yù)期
7、flush隊(duì)列、callqueue長(zhǎng)度、compact隊(duì)列是否符合預(yù)期。前兩者的積壓都會(huì)造成系統(tǒng)不穩(wěn)定。
8、failedRequest和maxResponseTime
9、gc狀況，過(guò)長(zhǎng)的ygc和過(guò)頻的cms都需要警惕
運(yùn)維工具HBase官方版本的可運(yùn)維性的確很差，為了能最大限度的保證線上系統(tǒng)安全，快速定位故障原因，阿里做了很多建設(shè)性的工作。
1、建立了完整的監(jiān)控體系，根據(jù)日常測(cè)試和線上運(yùn)行經(jīng)驗(yàn)，加入了很多監(jiān)控點(diǎn)。
2、監(jiān)控的粒度達(dá)到region級(jí)別
3、call dump和線上慢請(qǐng)求追蹤功能
4、btrace腳本體系，出現(xiàn)問(wèn)題直接運(yùn)行查看程序內(nèi)部信息
5、日志收集和報(bào)警
6、在線表維護(hù)工具和storefile、logs分析工具
