2024年6月19日发(作者：)

技术

IGITCW

分析

Technology Analysis

基于开源工具的HBase监控与问题分析

许经伟，李公平，王文学，郝　睿，李　夏

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

摘要：在大规模的分布式服务HBase集群环境下，针对Web应用的访问异常进行问题分析是非常复杂和困难的。Web

应用的访问请求穿过了部署在几百个节点上的多层互相依赖的软件，难以跟踪和监控。为了方便在HBase应用环境下更好

的分析问题，整理了每一层软件的关键监控指标和适合的开源监控软件，并对常见的问题进行了分类，最后针对每一类问

题给出了解决方案。

关键词：HBase；Web应用；监控；分析

doi：10.3969/.1672-7274.2021.05.053

中图分类号：TP3 文献标示码：A 文章编码：1672-7274（2021）05-0120-05

HBase Monitoring and Problem Analysis Based on Open Source Tools

XU Jingwei,LI Gongping,WANG Wenxue,HAO Rui,LI Xia

(Anhui Branch of China Telecom Co., Ltd., Hefei 230000, China)

Abstract

：In the large-scale distributed service HBase cluster environment, it is very complicated and difficult to analyze

the access exceptions of Web applications. Access requests for Web applications pass through layers of interdependent software

deployed on hundreds of nodes and are difficult to track and monitor. In order to facilitate the better analysis of the problem in the

HBase application environment. We have sorted out the key monitoring indicators of each layer of software and suitable open source

monitoring software, classified the common problems, and finally provided solutions for each kind of problems.

Keywords

：HBase; Web applications; monitoring; analysis

0 引言

HBase作为一种可扩展的NOSQL数据库，能够部

署到上千台机器上，存储数十亿行，在PB级别数据量

上提供根据Rowkey的低延迟接口查询

[1]

。HBase自身

已经实现了一定程度的容错性高可用性。但要想稳定的

使用HBase提供实时接口查询，需要建立对HBase应用

的一整套监控和分析方法。这需要建立对整个接口查询

链路上各种组件的监控，这些组件包括了调用HBase服

务的Tomcat、WebLogic等常见Web容器，以及HBase

和HDFS实例。并且还要引入一些开源工具对Web容器

实例、HBase实例、HDFS实例进行性能分析和故障分析。

客户端访问HBase应用的整个链路涉及到若干个部分，

包括HBase客户端、HBase服务、HDFS服务和操作系统。

分析HBase应用需要监控以上服务或基础设施的关键指

标。

1 服务端监控

1.1 监控指标

服务端监控指标包括Kerberos服务、HBase服务、

HDFS服务和服务端主机监控指标。

Kerberos认证服务监控指标包括KDC的服务状态、

KDC的认证时长。

HBase服务监控指标包括HBase Master监控、

Region Server监控、Table监控、Region监控几部分。

（1）HBase Master监控指标包括Region Assign指

标、Server指标。Region Assign监控指标包括RIT时

长、RIT数量、Assign次数、批量Assign次数；Server

指标包括平均负载、Active RegionServer数量、Dead

RegionServer数量、总请求数。

（2）RegionServer监控指标包括JVM指标、线程指

标、Server指标、IPC指标。JVM指标包括堆内存使用率、

GC时长、GC次数、阻塞线程数、可运行线程数、等待

线程数、定时等待线程数；线程指标包括当前线程数量、

线程数量峰值；Server指标包括Region数量、Store数量、

读取请求数、写入请求数、分裂队列长度、刷新队列长度、

压缩队列长度、hedge读取次数；IPC指标包括队列长度、

打开连接数、P75处理时长、P90处理时长、P95处理时

长、P98处理时长、P99处理时长、P999处理时长、

P75

队列时长、P90队列时长、P95队列时长、P98队列时长、

P99队列时长、P999队列时长。

（3）Region监控指标包括Store数量、Store文件数量、

MemStore大小、Store文件大小、读取请求数、写入请

求数、Append次数、Delete次数、Get次数、Mutate次数、

Scan次数、Increment次数。HDFS监控包括NameNode

监控、DataNode监控。

（4）NameNode监控指标包括JVM指标、文件系统

作者简介：许经伟（1985-） ，男，汉族，高级工程师，学士，主要研究方向为数据挖掘、大数据建模。

120

DIGITCW

2021.05

指标、RPC指标、RPC活动详情指标、文件系统状态指标。

JVM指标包括堆内存使用率、GC时长、GC次数、阻

塞线程数、可运行线程数、等待线程数、定时等待线程数；

文件系统指标包括总块数、总文件数、丢失块数量、损

坏块数量、副本不足块数量、待定删除块数量、待复制

块数量、总负载、容量使用率、锁队列长度；RPC指标

包括用户打开连接数、RPC入队列次数、RPC队列平均

时长、RPC处理次数、RPC处理平均时长、RPC认证失

败次数、RPC认证成功次数、RPC授权成功次数、RPC

授权失败次数、打开连接数、调用队列长度、缓慢RPC

次数；RPC活动详情指标包括获取块位置次数、获取块

位置平均时长、获取块次数、获取块平均时长、创建文

件次数、创建文件平均时长、创建目录次数、创建目录

平均时长、获取文件信息次数、获取文件信息平均时长、

删除文件次数、删除文件平均时长、fsync次数、fsync

平均时长、complete操作次数、compete操作平均时长、

追加写次数、追加写平均时长；文件系统状态指标包括

文件系统状态、活动DataNode数量、死亡DataNode数

量、卷损坏数量、过期的DataNode数量、过期的卷数量、

TopUser及操作数量、维护状态的DataNode数量。

（5）DataNode监控指标包括DataNode活动指标、

JVM指标、RPC活动指标。DataNode活动指标包括损

坏卷数量、读取块平均响应时长、写入块平均响应时

长、块汇报次数、块汇报平均时长、增量块汇报次数、

增量块汇报平均时长、flush平均时长、fsync平均时长；

JVM指标包括堆内存使用率、GC时长、GC次数、阻

塞线程数、可运行线程数、等待线程数、定时等待线程数。

基础设施监控包括主机CPU监控、主机内存监控、

主机磁盘监控。主机CPU监控指标包括CPU使用率、

平均负载；主机内存监控指标包括内存使用率、交换区

使用率、脏页字节数、物理内存写回磁盘字节数；主机

磁盘监控指标包括读取字节数、写入字节数、读取次数、

写入次数、磁盘使用率、磁盘队列时间、磁盘队列长度、

磁盘服务时间；主机网络监控指标包括接收字节数、发

送字节数、接收包数量、发送包数量、接收丢包数、发

送丢包数、TCP

连接数、DNS解析时长。

1.2 监控软件

在IT服务监控领域，存在着大量的开源监控软

件，包括Zabbix、Nagios、OpenTSDB、Prometheus等。

Prometheus是由Google开源的监控报警系统和时序列

数据库（TSDB）。Prometheus使用Go语言开发，是

Google公司BorgMon监控系统的开源版本，性能足够

支撑上万台规模的集群。

近几年兴起的监控系统大部分都选择了将数据存储

Technology Analysis

技术分析

DCW

在时序型数据库中，Prometheus用的就是自研的TSDB，

时序数据库在高并发的情况下，读写性能远高于传统的

关系数据库，另外Prometheus还提供了很多内置的基于

时间的处理函数，简化数据聚合的难度。

Prometheus在收集数据时，采用的Pull模型（服务

端主动去客户端拉取数据），Pull模型在云环境中有着比

较大的优势，原因是分布式系统中，一定是有中心节点

知道整个集群信息的，那么通过中心节点就可以完成所

有要监控节点的服务发现和数据拉取。

Zabbix适合监控对象增减不频繁的情况，如基础设

施监控，而Prometheus适合集群环境下，监控对象频繁

增减的情况。

Prometheus的基本原理是通过HTTP协议周期性抓

取被监控组件的状态，任意组件只要提供对应的HTTP

接口就可以接入监控。输出被监控组件信息的HTTP接

口叫做exporter。目前常用的开源组件大部分都有自带

的exporter可用，如haproxy、nginx、mysql、linux操作

系统，但是Hadoop生态圈的组件并没有自带的exporter

可用，所以需要针对HBase、hdfs开发对应的exporter

软件Prometheus中的AlertManager负责将Prometheus

产生的报警信息发送到各种通知的渠道，如邮件、短信、

微信等。在实际操作中，一般会配置一个通知脚本完成

后续的短信通知。

2 客户端监控

2.1 监控指标

客户端监控指标包括Web容器监控指标、应用响应

指标。Web容器监控指标包括堆内存使用率、GC时长、

GC次数、阻塞线程数、可运行线程数、等待线程数、

定时等待线程数；应用响应指标包括调用成功率、调用

响应时长、应用负载。

2.2 监控软件

应用侧一般是Java Web应用程序，部署在Tomcat

或其他Web容器中。对于这些实例的监控，我们采用

Prometheus监控JVM相关的性能信息，采用Pinpoint监

控客户端调用HBase服务的响应时长、异常信息和远程

调用方法栈，采用阿里巴巴的Arthas监控实时的JVM

方法调用耗时。

Pinpoint是基于Google Dapper论文的一款全链路分

析工具实现，提供了无侵入式的调用链监控等。

3 问题分析

在由HBase客户端、HBase服务、HDFS服务构成

的复杂环境下，HBase客户端发生报错或者响应缓慢的

情况应该按照HBase客户端、HBase服务端、HDFS服

2021.05

数字通信世界

121

技术

IGITCW

分析

Technology Analysis

务的调用顺序依次进行分析。

3.1 HBase客户端分析

HBase客户端一般运行在Web容器中，对外提供实

时查询服务。当对外的实时查询服务出现异常时，需要

分析主机和Web容器相关的问题。

3.1.1 主机相关问题分析

主机相关的问题中，主要关注主机宕机、操作系统

资源耗尽这几种情况。

（1）主机宕机

如果Web容器所在的主机宕机，那么主机上部署的

Web容器也不能正常提供服务。主机宕机一般可能因为

硬件故障、人为关机和交换区耗尽造成。一是硬件故障

引起的主机宕机，通过ping监控很容易发现。这种情况

需要更换故障硬件处理。二是认为关机造成的主机宕机，

也可以通过ping监控发现。将主机启动即可，启动后在

系统操作日志中可以看到关机的操作记录。三是当交换

区耗尽时，一般物理内存也会耗尽。这时主机可以ping

通，但主机上运行的Web容器和监控程序都会不响应。

这种情况需要通过SSH登陆监控来探测，重启主机即可

解决问题。

（2）操作系统资源耗尽

Web容器在运行时，需要向操作系统申请CPU、文

件句柄、进程等资源。当Web容器申请的此类资源达到

操作系统当前用户的限制，就会导致调用失败。一是主

机CPU使用率持续100%，程序运行缓慢。这种情况通

过监控可以提前发现。二是文件句柄耗尽，通常由应用

未释放资源引起，通过监控可以提前发现。三是进程数

达到限制，通常由应用未释放资源引起，通过监控可以

提前发现。四是文件系统满，通过df可以查看文件系统

空间限制，通过监控可以提前发现。

3.1.2 Web容器相关问题分析

（1）服务进程退出

如果Web容器进程因为某些异常或者其他情况造成

进程退出，那么服务端口也不会监听。如果客户端调用

服务返回端口不存在的异常，那么可以断定是Web容器

退出导致调用失败。在Web容器的日志中会记录退出的

原因，可能的原因有：一是被用户用kill命令杀死，在

应用日志和操作系统日志中会看到kill操作记录；二是

主机操作系统崩溃或者维护重启后Web容器没有自动拉

起，通过linux主机的/var/log/message日志可以看到重

启发生的时间和异常信息；三是JVM内存溢出导致进

程退出，在日志中会看到OutOfMemory的异常；四是

JVM缺陷导致进程退出，在web容器目录下会看到hs_

err_pid**.log的日志。

122

DIGITCW

2021.05

（2）分配的资源耗尽

一是数据库连接池满造成服务响应缓慢，在日志中

会看到连接池满的异常。这种情况需要排查数据库连接

使用完毕后有没有合理地关闭。二是内存溢出造成服务

响应缓慢，在日志中会看到OutOfMemory的异常。这种

情况需要用jmap工具导出Java堆，离线分析堆中是否

分配了大量对象，这些对象在短期内不能被垃圾回收机

制清理。三是线程池满造成服务响应缓慢。这种情况需

要使用jstack导出threaddump文件，分析线程等待的对

象，找出引起线程池满的原因。也可以使用arthus工具，

在线对线程池进行诊断，

（3）依赖服务问题

Web容器依赖的关系数据库、HBase等服务性能下

降，造成服务响应缓慢。这种情况需要部署pinpoint、

skywalker等apm工具，监控相关的外部服务异常率、

响应时长、方法栈，进一步找出Web容器响应缓慢的直

接原因。一是关系数据库性能差。如果是Oracle数据库，

需要结合Oracle数据库的AWR、ASH、ADDM报表，

优化性能差的SQL语句；如果是MySQL数据库，需要

结合慢日志分析，找出并优化性能差的SQL语句。二是

HBase性能差。这种情况放在下面分析。

3.2 HBase服务分析

HBase服务相关的问题中，主要关注资源竞争、负

载不均衡、配置错误、Region状态异常这几种情况。

3.2.1 资源竞争

HBase单个Region Server的负载上限约为8000个

请求/秒，当某个Region Server上发生批处理作业查询

HBase的情况，批处理作业的批量scan请求就会占满请

求队列，其他的少量scan或get操作就会在队列中超时。

使用hive批处理写入Hbase也是类似的情况。

为了解决此问题，HBase引入了Region Server分组

的机制。每个分组包括若干个RegionServer，不同业务

下的表通过配置RSGroup属性的方式部署在不同分组。

Hbase通过RSGroup实现了不同业务的物理隔离，解决

了资源竞争的问题。

3.2.2 负载不均衡

负载均衡，英文名称为Load Balance，其意思就是

分摊到多个操作单元上进行执行，例如Web服务器、

FTP服务器、企业关键应用服务器和其他关键任务服务

器等，从而共同完成工作任务。

正常情况下，对HBase的访问请求是按照RowKey

平均分布到若干个Region上的，而这若干个Region是

平均分布在若干个Region Server上的。

在负载不均衡的情况下，大部分的访问请求都落在

某几个Region上。这样会造成处理效率降低，也会造成

Region所在的RegionServer的handler、内存等资源耗尽，

部署在该Region Server上的其他业务也会受到很大的影

响。

（1）rowkey设计不合理

HBase中RowKey可以惟一标识一行记录，在

HBase中检索数据有三种方式：一是通过get方式，指

定RowKey获取惟一一条记录；二是通过scan方式，设

置startRow和stopRow 参数进行范围匹配；三是全表扫

描，即直接扫描整张表中所有行记录。

通常在关系数据库中，主键是以序列形式递增的。

如果将这种方式照搬到HBase数据库，在插入的场景下，

数据永远会插入到最新的一个Region中，这样就造成

了数据热点。通过RowKey设计避免数据热点有三种方

法。一是反转。如果RowKey在数据分布上不均匀，但

RowKey尾部的数据却呈现出了良好的随机性，可以考

虑将RowKey的信息反转。反转可以有效的使RowKey

随机分布，但是牺牲了RowKey的有序性。二是加盐。

加盐的原理是在原RowKey的前面添加固定长度的随机

数，也就是给RowKey分配一个随机前缀使它和之间的

RowKey的开头不同。随机数能保障数据在所有Regions

间的负载均衡。三是哈希。基于RowKey的完整或部分

数据进行Hash，而后将Hash后的值完整替换或部分替

换原RowKey的前缀部分。这里说的hash包含MD5、

sha1、sha256或sha512等算法。

（2）region分布不均

HBase Master有一个内置的叫做均衡器的特性。在

默认的情况下，HBase Master会每五分钟运行一次。一

旦均衡器启动，它将尝试均匀分配

region到所有region

服务器。

当均衡器没有正常工作时，部分RegionServer会

部署大量的Region，而部分RegionServer会部署少量

的Region，这样也会导致负载不均衡。有两种情况会

导致均衡器没有正常工作：一是均衡器没有开启；二是

HBase集群中存在长期处于迁移状态的Region。如果均

衡器没有开启，手动开启均衡器就可以解决问题。如果

因为存在长期处于迁移状态的Region造成均衡器不工

作，需要先解决长期处于迁移状态的Region，才能开启

均衡器。

（3）小region过热

HBase设计出来是为了存储数十亿行、TB级存储的

海量数据，但实践中也会用来存储一些100 M左右的数

据。按照HBase默认的配置，10 G大小一个Region，所

以这些数据都会存储到一个Region里面。当此类Region

遇到大量查询时，负载会落到1个RegionServer上，造

Technology Analysis

技术分析

DCW

成RegionServer过载。以上问题有两种解决办法：一是

按照负载情况，将小Region继续拆分，用于分担负载；

二是将此类小表迁移到Redis内存数据库中提供查询。

3.2.3 配置错误

（1）客户端配置

①表Region大小配置。为了避免HBase运行时分

裂影响读写性能，一般会在集群级别设置最大文件大小

为一个较大的值，在建表前根据表大小预估分区数，将

HBase表分为若干个分区。在客户端建表语句中也可以

指定MAX_FILESIZE参数，这样客户端配置会覆盖服

务端的配置。以Hbase批量导入为例，在批量导入后会

遇到Region持续分裂的合并的问题，严重影响Hbase表

的访问。

②客户端重试配置。为了避免瞬时的网络抖动影

响HBase客户端的查询，一般会在Hbase客户端配置

参数和参数。

这两个参数含义分别为重试次数和重试间隔，重试间隔

单位为毫秒。正常情况下，客户端在放弃本次操作之前，

会在几秒内进行若干次重试，每次间隔为几十毫秒。但

是经常存在客户端将重试间隔配置为秒级，这样客户端

就会一直卡住，造成故障。

（2）服务端配置

大合并配置。HBase是一种Log-Structured Merge

Tree架构模式，用户数据写入先写WAL，再写缓存，满

足一定条件后缓存数据会执行flush操作真正落盘，形

成一个数据文件HFile。随着数据写入不断增多，flush

次数也会不断增多，进而HFile数据文件就会越来越

多。然而，太多数据文件会导致数据查询IO次数增多，

因此HBase尝试着不断对这些文件进行合并，这个合

并过程称为Compaction。HBase配置了n.

majorcompaction用于控制major compaction的间隔，这

个设置默认为7天。对于存在大量Region的HBase集

群，一般倾向于在闲时进行major compaction。无论

这个设置为什么数值，均无法保证在闲时进行major

compation。所以这个配置一般配置为0

[2]

，即禁用自动

的major compaction，并且部署定时任务，在闲时触发

major compaction。

3.2.4 Region异常

（1）Region下线

HBase集群在读写过程中，可能由于Region分

裂或Region均衡等导致Region的短暂下线，此

时客户端与HBase集群进行RPC操作时会抛出

NotServingRegionException异常，从而导致读写操作失

败。从服务端考虑，应尽量预分区，避免Region自动分

裂。对于Region均衡，应在忙时关闭均衡，在每天读写

2021.05

数字通信世界

123

技术

IGITCW

分析

Technology Analysis

压力较小时闲时打开，触发均衡操作。从客户端考虑，

要保证region下线期间，读写请求能在region上线后恢

复。对于写操作，应将未写入成功的记录，放到缓存中，

每隔一段时间交给一个后台线程重新提交。对于读操作，

可以合理设置重试次数。

（2）长期RIT状态

RIT是Region In Transition的缩写，是指在一次操

作中Region处于迁移状态。迁移状态本来是HBase操

作中的正常状态，但是因为各种原因，有些Region会处

于长时间的RIT状态，必须人为干预才能解决。

如果Region长时间处在PENDING_CLOSE状态，

一般重启Hbase Master就可以解决；如果Region长时

间处在FAILED_OPEN状态，一般是是HBase Meta表

与HDFS文件中的元数据信息不一致，通过查看Region

Server日志可以定位到问题，后续使用hbck工具使

Hbase Meta表中元数据与HDFS文件中的元数据信息一

致即可。

降，这需要查看NameNode进程自带的JMX信息，采

集平均响应时长、平均队列时长、负载、RPC队列等指

标进一步的分析问题。

3.3.2 DataNode异常

HBase数据在写入缓存（MemStore）前首先把数据

顺序写入HLog中，这种设计在遇到RegionServer宕机时，

可以从HLog中回放日志，保证数据不丢失。

HLog会同时写入三个副本到DataNode。当某个

DataNode响应速度慢，HLog的写入速度也会变慢，相

应的HBase写入操作就会变慢。一般在RegionServer

中会打印出“slow sync cost： 230 ms current pipeline

DataNode IP地址”类似的日志。

这种情况需要检查DataNode是否有坏盘，或者

DataNode的磁盘是否存在写入竞争，导致响应速度变慢。

如果有坏盘，需要及时更换损坏的磁盘；如果磁盘存在

写入竞争，需要根据业务决定是否将HBase集群单独部署。

3.3 HDFS服务分析

3.3.1 NameNode异常

NameNode管理着文件系统树和所有文件、目录的

元数据。Name Node记录着每个文件中各个块所在的数

据节点的位置信息。

在生产环境下，NameNode一般会采用高可用架构。

在高可用架构中，会同时启动两个NameNode，一个处

于active状态，另一个处于standby状态。这样，当一个

NameNode所在的服务器宕机时，可以在数据不丢失的

情况下，切换到另一个NameNode提供服务。

两个NameNode同时宕机的情况极少发生，当一个

NameNode发生宕机，通过Prometheus监控系统就可以

及时得到通知。更容易遇到的情况是NameNode性能下

（上接第40页）

合理部署，从源头上切断安全威胁行为，

全面保证各项公证信息的安全性。

此外，公证行业在实现内部发展的同时还需注重与

外部的联系，例如外事、公安、法院、档案等部门均是

重要的对接对象，需要形成稳定可靠的信息资源对接关

系，多方主体就公证信息资源管理的方法作出商讨，达

成共识，制定一套具有协同性与可行性的工作方案并将

其落实到位。积极打破行业的数据鸿沟，消除数据沟通

阻碍，由原本的部门内查询转变为跨部门的数据共享互

查模式，在此条件下保证公证服务的质量，切实提高公

证服务的效率。

4 结束语

通过实际案例的研究发现，在使用Web应用访问

HBase集群的整个调用过程中会遇到很多异常情况。将

这些异常情况进行了分类，并且按照分类详细分析了每

一种异常情况，针对可能发生异常的对象制定了详细的

监控指标，并给出了监控方案，用于及时发现异常情况。

最后，针对文中提出各种的异常情况，提出了可行的解

决方案。

参考文献

[1] George ：the definitive guide：random access to your planet-size

data[M]."O'Reilly Media，Inc."，2011.

[2] Jiang Administration Cookbook[M].Packt Publishing Ltd，2012.

联网+”的普及，给公证行业的发展带来全新的机遇，

同时也面临诸多挑战。为顺应时代的发展潮流，公证行

业需要对自身的职能定位形成准确的认识，广泛掌握社

会新需求，形成适用于近期、中期及远期的发展规划，

依托于互联网平台，提高公证的信息化水平，在保留原

公证行业优质工作模式的同时实现创新式发展。

参考文献

[1] 刘崴.公证信息化建设的现状分析和发展方向[J].中国司法，2016（07）：

55-59.

[2] 宫楠，卜天石.公证信息化道路问题初探[J].中国公证，2019（03）：45-

49.

[3] 吕维超.公证信息化建设的现状分析和发展方向[J].法制与社会，2019

（25）：106-107.

4 结束语

综上所述，在社会经济良好发展的背景下，加之“互

124

DIGITCW

2021.05