基于開源工具的HBase 監(jiān)控與問題分析

許經(jīng)偉，李公平，王文學，郝 睿，李 夏

（中國電信股份有限公司安徽分公司，安徽 合肥 230000）

0 引言

HBase 作為一種可擴展的NOSQL 數(shù)據(jù)庫，能夠部署到上千臺機器上，存儲數(shù)十億行，在PB 級別數(shù)據(jù)量上提供根據(jù)Rowkey 的低延遲接口查詢[1]。HBase 自身已經(jīng)實現(xiàn)了一定程度的容錯性高可用性。但要想穩(wěn)定的使用HBase 提供實時接口查詢，需要建立對HBase 應用的一整套監(jiān)控和分析方法。這需要建立對整個接口查詢鏈路上各種組件的監(jiān)控，這些組件包括了調用HBase 服務的Tomcat、WebLogic 等常見Web 容器，以及HBase和HDFS 實例。并且還要引入一些開源工具對Web 容器實例、HBase 實例、HDFS 實例進行性能分析和故障分析?？蛻舳嗽L問HBase 應用的整個鏈路涉及到若干個部分，包括HBase 客戶端、HBase 服務、HDFS 服務和操作系統(tǒng)。分析HBase 應用需要監(jiān)控以上服務或基礎設施的關鍵指標。

1 服務端監(jiān)控

1.1 監(jiān)控指標

服務端監(jiān)控指標包括Kerberos 服務、HBase 服務、HDFS 服務和服務端主機監(jiān)控指標。

Kerberos 認證服務監(jiān)控指標包括KDC 的服務狀態(tài)、KDC 的認證時長。

HBase 服務監(jiān)控指標包括HBase Master 監(jiān)控、Region Server 監(jiān)控、Table 監(jiān)控、Region 監(jiān)控幾部分。

（1）HBase Master 監(jiān)控指標包括Region Assign 指標、Server 指標。Region Assign 監(jiān)控指標包括RIT 時長、RIT 數(shù)量、Assign 次數(shù)、批量Assign 次數(shù)；Server指標包括平均負載、Active RegionServer 數(shù)量、Dead RegionServer 數(shù)量、總請求數(shù)。

（2）RegionServer 監(jiān)控指標包括JVM 指標、線程指標、Server 指標、IPC 指標。JVM 指標包括堆內存使用率、GC 時長、GC 次數(shù)、阻塞線程數(shù)、可運行線程數(shù)、等待線程數(shù)、定時等待線程數(shù)；線程指標包括當前線程數(shù)量、線程數(shù)量峰值；Server 指標包括Region 數(shù)量、Store 數(shù)量、讀取請求數(shù)、寫入請求數(shù)、分裂隊列長度、刷新隊列長度、壓縮隊列長度、hedge 讀取次數(shù)；IPC 指標包括隊列長度、打開連接數(shù)、P75處理時長、P90處理時長、P95處理時長、P98處理時長、P99處理時長、P999處理時長、P75隊列時長、P90隊列時長、P95隊列時長、P98隊列時長、P99隊列時長、P999隊列時長。

（3）Region 監(jiān)控指標包括Store 數(shù)量、Store 文件數(shù)量、MemStore 大小、Store 文件大小、讀取請求數(shù)、寫入請求數(shù)、Append 次數(shù)、Delete 次數(shù)、Get 次數(shù)、Mutate 次數(shù)、Scan 次數(shù)、Increment 次數(shù)。HDFS 監(jiān)控包括NameNode監(jiān)控、DataNode 監(jiān)控。

（4）NameNode 監(jiān)控指標包括JVM 指標、文件系統(tǒng)指標、RPC 指標、RPC 活動詳情指標、文件系統(tǒng)狀態(tài)指標。JVM 指標包括堆內存使用率、GC 時長、GC 次數(shù)、阻塞線程數(shù)、可運行線程數(shù)、等待線程數(shù)、定時等待線程數(shù)；文件系統(tǒng)指標包括總塊數(shù)、總文件數(shù)、丟失塊數(shù)量、損壞塊數(shù)量、副本不足塊數(shù)量、待定刪除塊數(shù)量、待復制塊數(shù)量、總負載、容量使用率、鎖隊列長度；RPC 指標包括用戶打開連接數(shù)、RPC 入隊列次數(shù)、RPC 隊列平均時長、RPC 處理次數(shù)、RPC 處理平均時長、RPC 認證失敗次數(shù)、RPC 認證成功次數(shù)、RPC 授權成功次數(shù)、RPC授權失敗次數(shù)、打開連接數(shù)、調用隊列長度、緩慢RPC次數(shù)；RPC 活動詳情指標包括獲取塊位置次數(shù)、獲取塊位置平均時長、獲取塊次數(shù)、獲取塊平均時長、創(chuàng)建文件次數(shù)、創(chuàng)建文件平均時長、創(chuàng)建目錄次數(shù)、創(chuàng)建目錄平均時長、獲取文件信息次數(shù)、獲取文件信息平均時長、刪除文件次數(shù)、刪除文件平均時長、fsync 次數(shù)、fsync平均時長、complete 操作次數(shù)、compete 操作平均時長、追加寫次數(shù)、追加寫平均時長；文件系統(tǒng)狀態(tài)指標包括文件系統(tǒng)狀態(tài)、活動DataNode 數(shù)量、死亡DataNode 數(shù)量、卷損壞數(shù)量、過期的DataNode 數(shù)量、過期的卷數(shù)量、TopUser 及操作數(shù)量、維護狀態(tài)的DataNode 數(shù)量。

（5）DataNode 監(jiān)控指標包括DataNode 活動指標、JVM 指標、RPC 活動指標。DataNode 活動指標包括損壞卷數(shù)量、讀取塊平均響應時長、寫入塊平均響應時長、塊匯報次數(shù)、塊匯報平均時長、增量塊匯報次數(shù)、增量塊匯報平均時長、flush 平均時長、fsync 平均時長；JVM 指標包括堆內存使用率、GC 時長、GC 次數(shù)、阻塞線程數(shù)、可運行線程數(shù)、等待線程數(shù)、定時等待線程數(shù)。

基礎設施監(jiān)控包括主機CPU 監(jiān)控、主機內存監(jiān)控、主機磁盤監(jiān)控。主機CPU 監(jiān)控指標包括CPU 使用率、平均負載；主機內存監(jiān)控指標包括內存使用率、交換區(qū)使用率、臟頁字節(jié)數(shù)、物理內存寫回磁盤字節(jié)數(shù)；主機磁盤監(jiān)控指標包括讀取字節(jié)數(shù)、寫入字節(jié)數(shù)、讀取次數(shù)、寫入次數(shù)、磁盤使用率、磁盤隊列時間、磁盤隊列長度、磁盤服務時間；主機網(wǎng)絡監(jiān)控指標包括接收字節(jié)數(shù)、發(fā)送字節(jié)數(shù)、接收包數(shù)量、發(fā)送包數(shù)量、接收丟包數(shù)、發(fā)送丟包數(shù)、TCP 連接數(shù)、DNS 解析時長。

1.2 監(jiān)控軟件

在IT 服務監(jiān)控領域，存在著大量的開源監(jiān)控軟件，包括Zabbix、Nagios、OpenTSDB、Prometheus 等。Prometheus 是由Google 開源的監(jiān)控報警系統(tǒng)和時序列數(shù)據(jù)庫（TSDB）。Prometheus 使用Go 語言開發(fā)，是Google 公司BorgMon 監(jiān)控系統(tǒng)的開源版本，性能足夠支撐上萬臺規(guī)模的集群。

近幾年興起的監(jiān)控系統(tǒng)大部分都選擇了將數(shù)據(jù)存儲在時序型數(shù)據(jù)庫中，Prometheus 用的就是自研的TSDB，時序數(shù)據(jù)庫在高并發(fā)的情況下，讀寫性能遠高于傳統(tǒng)的關系數(shù)據(jù)庫，另外Prometheus 還提供了很多內置的基于時間的處理函數(shù)，簡化數(shù)據(jù)聚合的難度。

Prometheus 在收集數(shù)據(jù)時，采用的Pull 模型（服務端主動去客戶端拉取數(shù)據(jù)），Pull 模型在云環(huán)境中有著比較大的優(yōu)勢，原因是分布式系統(tǒng)中，一定是有中心節(jié)點知道整個集群信息的，那么通過中心節(jié)點就可以完成所有要監(jiān)控節(jié)點的服務發(fā)現(xiàn)和數(shù)據(jù)拉取。

Zabbix 適合監(jiān)控對象增減不頻繁的情況，如基礎設施監(jiān)控，而Prometheus 適合集群環(huán)境下，監(jiān)控對象頻繁增減的情況。

Prometheus 的基本原理是通過HTTP 協(xié)議周期性抓取被監(jiān)控組件的狀態(tài)，任意組件只要提供對應的HTTP接口就可以接入監(jiān)控。輸出被監(jiān)控組件信息的HTTP 接口叫做exporter。目前常用的開源組件大部分都有自帶的exporter 可用，如haproxy、nginx、mysql、linux 操作系統(tǒng)，但是Hadoop 生態(tài)圈的組件并沒有自帶的exporter可用，所以需要針對HBase、hdfs 開發(fā)對應的exporter軟件Prometheus 中的AlertManager 負責將Prometheus產(chǎn)生的報警信息發(fā)送到各種通知的渠道，如郵件、短信、微信等。在實際操作中，一般會配置一個通知腳本完成后續(xù)的短信通知。

2 客戶端監(jiān)控

2.1 監(jiān)控指標

客戶端監(jiān)控指標包括Web 容器監(jiān)控指標、應用響應指標。Web 容器監(jiān)控指標包括堆內存使用率、GC 時長、GC 次數(shù)、阻塞線程數(shù)、可運行線程數(shù)、等待線程數(shù)、定時等待線程數(shù)；應用響應指標包括調用成功率、調用響應時長、應用負載。

2.2 監(jiān)控軟件

應用側一般是Java Web 應用程序，部署在Tomcat或其他Web 容器中。對于這些實例的監(jiān)控，我們采用Prometheus 監(jiān)控JVM 相關的性能信息，采用Pinpoint 監(jiān)控客戶端調用HBase 服務的響應時長、異常信息和遠程調用方法棧，采用阿里巴巴的Arthas 監(jiān)控實時的JVM方法調用耗時。

Pinpoint 是基于Google Dapper 論文的一款全鏈路分析工具實現(xiàn)，提供了無侵入式的調用鏈監(jiān)控等。

3 問題分析

在由HBase 客戶端、HBase 服務、HDFS 服務構成的復雜環(huán)境下，HBase 客戶端發(fā)生報錯或者響應緩慢的情況應該按照HBase 客戶端、HBase 服務端、HDFS 服務的調用順序依次進行分析。

3.1 HBase 客戶端分析

HBase 客戶端一般運行在Web 容器中，對外提供實時查詢服務。當對外的實時查詢服務出現(xiàn)異常時，需要分析主機和Web 容器相關的問題。

3.1.1 主機相關問題分析

主機相關的問題中，主要關注主機宕機、操作系統(tǒng)資源耗盡這幾種情況。

（1）主機宕機

如果Web 容器所在的主機宕機，那么主機上部署的Web 容器也不能正常提供服務。主機宕機一般可能因為硬件故障、人為關機和交換區(qū)耗盡造成。一是硬件故障引起的主機宕機，通過ping 監(jiān)控很容易發(fā)現(xiàn)。這種情況需要更換故障硬件處理。二是認為關機造成的主機宕機，也可以通過ping 監(jiān)控發(fā)現(xiàn)。將主機啟動即可，啟動后在系統(tǒng)操作日志中可以看到關機的操作記錄。三是當交換區(qū)耗盡時，一般物理內存也會耗盡。這時主機可以ping通，但主機上運行的Web 容器和監(jiān)控程序都會不響應。這種情況需要通過SSH 登陸監(jiān)控來探測，重啟主機即可解決問題。

（2）操作系統(tǒng)資源耗盡

Web 容器在運行時，需要向操作系統(tǒng)申請CPU、文件句柄、進程等資源。當Web 容器申請的此類資源達到操作系統(tǒng)當前用戶的限制，就會導致調用失敗。一是主機CPU 使用率持續(xù)100%，程序運行緩慢。這種情況通過監(jiān)控可以提前發(fā)現(xiàn)。二是文件句柄耗盡，通常由應用未釋放資源引起，通過監(jiān)控可以提前發(fā)現(xiàn)。三是進程數(shù)達到限制，通常由應用未釋放資源引起，通過監(jiān)控可以提前發(fā)現(xiàn)。四是文件系統(tǒng)滿，通過df 可以查看文件系統(tǒng)空間限制，通過監(jiān)控可以提前發(fā)現(xiàn)。

3.1.2 Web 容器相關問題分析

（1）服務進程退出

如果Web 容器進程因為某些異常或者其他情況造成進程退出，那么服務端口也不會監(jiān)聽。如果客戶端調用服務返回端口不存在的異常，那么可以斷定是Web 容器退出導致調用失敗。在Web 容器的日志中會記錄退出的原因，可能的原因有：一是被用戶用kill 命令殺死，在應用日志和操作系統(tǒng)日志中會看到kill 操作記錄；二是主機操作系統(tǒng)崩潰或者維護重啟后Web 容器沒有自動拉起，通過linux 主機的/var/log/message 日志可以看到重啟發(fā)生的時間和異常信息；三是JVM 內存溢出導致進程退出，在日志中會看到OutOfMemory 的異常；四是JVM 缺陷導致進程退出，在web 容器目錄下會看到hs_err_pid**.log 的日志。

（2）分配的資源耗盡

一是數(shù)據(jù)庫連接池滿造成服務響應緩慢，在日志中會看到連接池滿的異常。這種情況需要排查數(shù)據(jù)庫連接使用完畢后有沒有合理地關閉。二是內存溢出造成服務響應緩慢，在日志中會看到OutOfMemory 的異常。這種情況需要用jmap 工具導出Java 堆，離線分析堆中是否分配了大量對象，這些對象在短期內不能被垃圾回收機制清理。三是線程池滿造成服務響應緩慢。這種情況需要使用jstack 導出threaddump 文件，分析線程等待的對象，找出引起線程池滿的原因。也可以使用arthus 工具，在線對線程池進行診斷，

（3）依賴服務問題

Web 容器依賴的關系數(shù)據(jù)庫、HBase 等服務性能下降，造成服務響應緩慢。這種情況需要部署pinpoint、skywalker 等apm 工具，監(jiān)控相關的外部服務異常率、響應時長、方法棧，進一步找出Web 容器響應緩慢的直接原因。一是關系數(shù)據(jù)庫性能差。如果是Oracle 數(shù)據(jù)庫，需要結合Oracle 數(shù)據(jù)庫的AWR、ASH、ADDM 報表，優(yōu)化性能差的SQL 語句；如果是MySQL 數(shù)據(jù)庫，需要結合慢日志分析，找出并優(yōu)化性能差的SQL 語句。二是HBase 性能差。這種情況放在下面分析。

3.2 HBase 服務分析

HBase 服務相關的問題中，主要關注資源競爭、負載不均衡、配置錯誤、Region 狀態(tài)異常這幾種情況。

3.2.1 資源競爭

HBase 單個Region Server 的負載上限約為8000 個請求/秒，當某個Region Server 上發(fā)生批處理作業(yè)查詢HBase 的情況，批處理作業(yè)的批量scan 請求就會占滿請求隊列，其他的少量scan 或get 操作就會在隊列中超時。使用hive 批處理寫入Hbase 也是類似的情況。

為了解決此問題，HBase 引入了Region Server 分組的機制。每個分組包括若干個RegionServer，不同業(yè)務下的表通過配置RSGroup 屬性的方式部署在不同分組。Hbase 通過RSGroup 實現(xiàn)了不同業(yè)務的物理隔離，解決了資源競爭的問題。

3.2.2 負載不均衡

負載均衡，英文名稱為Load Balance，其意思就是分攤到多個操作單元上進行執(zhí)行，例如Web 服務器、FTP 服務器、企業(yè)關鍵應用服務器和其他關鍵任務服務器等，從而共同完成工作任務。

正常情況下，對HBase 的訪問請求是按照RowKey平均分布到若干個Region 上的，而這若干個Region 是平均分布在若干個Region Server 上的。

在負載不均衡的情況下，大部分的訪問請求都落在某幾個Region 上。這樣會造成處理效率降低，也會造成Region 所在的RegionServer 的handler、內存等資源耗盡，部署在該Region Server 上的其他業(yè)務也會受到很大的影響。

（1）rowkey 設計不合理

HBase 中RowKey 可以惟一標識一行記錄，在HBase 中檢索數(shù)據(jù)有三種方式：一是通過get 方式，指定RowKey 獲取惟一一條記錄；二是通過scan 方式，設置startRow 和stopRow 參數(shù)進行范圍匹配；三是全表掃描，即直接掃描整張表中所有行記錄。

通常在關系數(shù)據(jù)庫中，主鍵是以序列形式遞增的。如果將這種方式照搬到HBase 數(shù)據(jù)庫，在插入的場景下，數(shù)據(jù)永遠會插入到最新的一個Region 中，這樣就造成了數(shù)據(jù)熱點。通過RowKey 設計避免數(shù)據(jù)熱點有三種方法。一是反轉。如果RowKey 在數(shù)據(jù)分布上不均勻，但RowKey 尾部的數(shù)據(jù)卻呈現(xiàn)出了良好的隨機性，可以考慮將RowKey 的信息反轉。反轉可以有效的使RowKey隨機分布，但是犧牲了RowKey 的有序性。二是加鹽。加鹽的原理是在原RowKey 的前面添加固定長度的隨機數(shù)，也就是給RowKey 分配一個隨機前綴使它和之間的RowKey 的開頭不同。隨機數(shù)能保障數(shù)據(jù)在所有Regions間的負載均衡。三是哈希?；赗owKey 的完整或部分數(shù)據(jù)進行Hash，而后將Hash 后的值完整替換或部分替換原RowKey 的前綴部分。這里說的hash 包含MD5、sha1、sha256或sha512等算法。

（2）region 分布不均

HBase Master 有一個內置的叫做均衡器的特性。在默認的情況下，HBase Master 會每五分鐘運行一次。一旦均衡器啟動，它將嘗試均勻分配region 到所有region服務器。

當均衡器沒有正常工作時，部分RegionServer 會部署大量的Region，而部分RegionServer 會部署少量的Region，這樣也會導致負載不均衡。有兩種情況會導致均衡器沒有正常工作：一是均衡器沒有開啟；二是HBase 集群中存在長期處于遷移狀態(tài)的Region。如果均衡器沒有開啟，手動開啟均衡器就可以解決問題。如果因為存在長期處于遷移狀態(tài)的Region 造成均衡器不工作，需要先解決長期處于遷移狀態(tài)的Region，才能開啟均衡器。

（3）小region 過熱

HBase 設計出來是為了存儲數(shù)十億行、TB 級存儲的海量數(shù)據(jù)，但實踐中也會用來存儲一些100 M 左右的數(shù)據(jù)。按照HBase 默認的配置，10 G 大小一個Region，所以這些數(shù)據(jù)都會存儲到一個Region 里面。當此類Region遇到大量查詢時，負載會落到1個RegionServer 上，造成RegionServer 過載。以上問題有兩種解決辦法：一是按照負載情況，將小Region 繼續(xù)拆分，用于分擔負載；二是將此類小表遷移到Redis 內存數(shù)據(jù)庫中提供查詢。

3.2.3 配置錯誤

（1）客戶端配置

①表Region 大小配置。為了避免HBase 運行時分裂影響讀寫性能，一般會在集群級別設置最大文件大小為一個較大的值，在建表前根據(jù)表大小預估分區(qū)數(shù)，將HBase 表分為若干個分區(qū)。在客戶端建表語句中也可以指定MAX_FILESIZE 參數(shù)，這樣客戶端配置會覆蓋服務端的配置。以Hbase 批量導入為例，在批量導入后會遇到Region 持續(xù)分裂的合并的問題，嚴重影響Hbase 表的訪問。

②客戶端重試配置。為了避免瞬時的網(wǎng)絡抖動影響HBase 客戶端的查詢，一般會在Hbase 客戶端配置hbase.client.retries.number 參數(shù)和hbase.client.pause 參數(shù)。這兩個參數(shù)含義分別為重試次數(shù)和重試間隔，重試間隔單位為毫秒。正常情況下，客戶端在放棄本次操作之前，會在幾秒內進行若干次重試，每次間隔為幾十毫秒。但是經(jīng)常存在客戶端將重試間隔配置為秒級，這樣客戶端就會一直卡住，造成故障。

（2）服務端配置

大合并配置。HBase 是一種Log-Structured Merge Tree 架構模式，用戶數(shù)據(jù)寫入先寫WAL，再寫緩存，滿足一定條件后緩存數(shù)據(jù)會執(zhí)行flush 操作真正落盤，形成一個數(shù)據(jù)文件HFile。隨著數(shù)據(jù)寫入不斷增多，flush次數(shù)也會不斷增多，進而HFile 數(shù)據(jù)文件就會越來越多。然而，太多數(shù)據(jù)文件會導致數(shù)據(jù)查詢IO 次數(shù)增多，因此HBase 嘗試著不斷對這些文件進行合并，這個合并過程稱為Compaction。HBase 配置了hbase.hregion.majorcompaction 用于控制major compaction 的間隔，這個設置默認為7 天。對于存在大量Region 的HBase 集群，一般傾向于在閑時進行major compaction。無論這個設置為什么數(shù)值，均無法保證在閑時進行major compation。所以這個配置一般配置為0[2]，即禁用自動的major compaction，并且部署定時任務，在閑時觸發(fā)major compaction。

3.2.4 Region 異常

（1）Region 下線

HBase 集群在讀寫過程中，可能由于Region 分裂 或Region均衡等導致Region的短暫下線，此時客戶端與HBase 集群進行RPC 操作時會拋出NotServingRegionException 異常，從而導致讀寫操作失敗。從服務端考慮，應盡量預分區(qū)，避免Region 自動分裂。對于Region 均衡，應在忙時關閉均衡，在每天讀寫壓力較小時閑時打開，觸發(fā)均衡操作。從客戶端考慮，要保證region 下線期間，讀寫請求能在region 上線后恢復。對于寫操作，應將未寫入成功的記錄，放到緩存中，每隔一段時間交給一個后臺線程重新提交。對于讀操作，可以合理設置重試次數(shù)。

（2）長期RIT 狀態(tài)

RIT 是Region In Transition 的縮寫，是指在一次操作中Region 處于遷移狀態(tài)。遷移狀態(tài)本來是HBase 操作中的正常狀態(tài)，但是因為各種原因，有些Region 會處于長時間的RIT 狀態(tài)，必須人為干預才能解決。

如果Region 長時間處在PENDING_CLOSE 狀態(tài)，一般重啟Hbase Master 就可以解決；如果Region 長時間處在FAILED_OPEN 狀態(tài)，一般是是HBase Meta 表與HDFS 文件中的元數(shù)據(jù)信息不一致，通過查看Region Server 日志可以定位到問題，后續(xù)使用hbck 工具使Hbase Meta 表中元數(shù)據(jù)與HDFS 文件中的元數(shù)據(jù)信息一致即可。

3.3 HDFS 服務分析

3.3.1 NameNode 異常

NameNode 管理著文件系統(tǒng)樹和所有文件、目錄的元數(shù)據(jù)。Name Node 記錄著每個文件中各個塊所在的數(shù)據(jù)節(jié)點的位置信息。

在生產(chǎn)環(huán)境下，NameNode 一般會采用高可用架構。在高可用架構中，會同時啟動兩個NameNode，一個處于active 狀態(tài)，另一個處于standby 狀態(tài)。這樣，當一個NameNode 所在的服務器宕機時，可以在數(shù)據(jù)不丟失的情況下，切換到另一個NameNode 提供服務。

兩個NameNode 同時宕機的情況極少發(fā)生，當一個NameNode 發(fā)生宕機，通過Prometheus 監(jiān)控系統(tǒng)就可以及時得到通知。更容易遇到的情況是NameNode 性能下降，這需要查看NameNode 進程自帶的JMX 信息，采集平均響應時長、平均隊列時長、負載、RPC 隊列等指標進一步的分析問題。

3.3.2 DataNode 異常

HBase 數(shù)據(jù)在寫入緩存（MemStore）前首先把數(shù)據(jù)順序寫入HLog 中，這種設計在遇到RegionServer 宕機時，可以從HLog 中回放日志，保證數(shù)據(jù)不丟失。

HLog 會同時寫入三個副本到DataNode。當某個DataNode 響應速度慢，HLog 的寫入速度也會變慢，相應的HBase 寫入操作就會變慢。一般在RegionServer中會打印出“slow sync cost：230 ms current pipeline DataNode IP 地址”類似的日志。

這種情況需要檢查DataNode 是否有壞盤，或者DataNode 的磁盤是否存在寫入競爭，導致響應速度變慢。如果有壞盤，需要及時更換損壞的磁盤；如果磁盤存在寫入競爭，需要根據(jù)業(yè)務決定是否將HBase 集群單獨部署。

4 結束語

通過實際案例的研究發(fā)現(xiàn)，在使用Web 應用訪問HBase 集群的整個調用過程中會遇到很多異常情況。將這些異常情況進行了分類，并且按照分類詳細分析了每一種異常情況，針對可能發(fā)生異常的對象制定了詳細的監(jiān)控指標，并給出了監(jiān)控方案，用于及時發(fā)現(xiàn)異常情況。最后，針對文中提出各種的異常情況，提出了可行的解決方案。