HBASE安装部署、参数设置、备份恢复、监控规范.docVIP

中国移动通信集团贵州有限公司 2014 年网络部网管数据集成与共享标准技术服务项目 1 30 HBASEHBASE 安装部署 参数设置 备份 恢复 安装部署 参数设置 备份 恢复 监控规范监控规范 普元信息技术股份有限公司普元信息技术股份有限公司 20142014 年年 1010 月月 中国移动通信集团贵州有限公司 2014 年网络部网管数据集成与共享标准技术服务项目 2 30 目录目录 1 1概述概述 3 3 1 1背景 3 1 2目的 4 1 3范围 4 2 2硬件准备硬件准备 5 5 3 3实施实施 5 5 3 1软件准备 5 3 2HBASE 服务器规划 5 3 3HBASE 安装部署 5 3 4HBASE 参数配置 9 3 5HBASE 备份恢复 10 3 5 1常用的在线备份方案及其比较 10 3 5 2原理 12 3 5 2 1Replication 总体结构 12 3 5 2 2Replication 工作流程 13 3 5 2 3Replication Class 简介 14 3 5 2 4Replication Zookeeper 上的结构 15 3 5 2 5Replication Failover 16 3 5 3部署 18 3 5 3 1Master 集群配置文件 18 3 5 3 2Slave 集群配置文件 20 3 5 3 3Master 集群配置 20 3 5 3 4Slave 集群配置 20 3 6HBASE 监控 20 3 6 1hbase 的监控配置说明 21 3 6 2hadoop 基于 ganglia 的监控框架 21 3 6 3hbase regionserver 中 RPC metric 的计算采集 22 3 6 4hbase 中 JVM 监控数据的计算采集 23 3 6 5hbase 中 regionserver 进程相关 metric 的计算采集 24 3 6 5 1region 的 metric 采集 25 3 6 5 2blockcache 相关的 metric 采集 26 3 6 5 3读写请求的 metric 采集 26 3 6 5 4dfs 操作的 metric 采集 27 3 6 5 5compact 与 split 的操作数据采集 28 3 6 5 6handler 的 metric 采集 29 可编辑修改 1 1概述概述 1 11 1背景背景 随着 OSS 域各个系统的建设 系统间数据共享的需求也越来越多 目前 贵州移动的 网管系统在总部规范指导下 按需逐年建设而成的 这些系统实现对通信网络和业务平台 的管理 支撑配置管理 故障监控 指标分析 网络优化 例行维护 指挥调度等工作 但是 面向网元和网络的分专业网管 难以支持以客户感知为核心 面向端到端业务实现 的运维管理新要求 越来越多的跨系统应用需要同时来自多个生产系统的数据进行支撑 实际生产分析场景需要将多类型 多专业的性能 质量等数据的进行集中管理 并建立模 型关联 准实时 非实时分析需求并存 CMOSS2 0 明确提出了数据集成和共享平台的技术架构要求 包括服务总线和数据总 线 数据集成和共享平台作为所有系统的交互桥梁 能够实现全面支持 CMOSS 规范中的 所有共享模式 提升系统稳定性及业务吞吐量 提供基于标准模型的数据共享服务 以解 决数据开放共享问题 建设效果直接影响到中国移动的 IT 业务能力和 IT 功能支撑能力 根据集团 CMOSS2 0 技术规范的要求 结合贵州移动在网管领域对数据共享的具体需 求 贵州移动规划建立网络数据共享平台 通过对生产系统数据准实时的采集 将数据汇 总到数据共享平台上 利用目前业界最新的数据分析和处理技术 按照不同的业务视角利 用采集到数据 为企业运营提供技术决策依据 同时 由于统计分析使用的数据和生产运 营的数据分离 可以较少对正式系统的影响 从而保障生产系统运营更加稳定 可靠 由于数据来自各个专业系统 需要面对不同的厂商 不同的技术架构 在数据共享平 台的建设过程中 存在数据标准化 服务标准化 大数据处理等问题 这些问题是数据集 成和共享平台建设成功的关键 需要重点解决 1 对现有网管数据从生产到消费的全流程梳理 形成网管数据血缘关系和数据地图 以 作为网管数据统一建模 集成共享的基础 2 根据数据地图 建立可扩展的 面向底层数据源和上层应用灵活适配的网管数据模型 作为数据共享中心模型标准 3 研究海量数据共享技术和模式 对数据库共享 数据编排 服务共享等数据共享技术 可编辑修改 和模式进行评估 制定符合网络数据中心的共享技术标准 4 Hadoop 是当前大数据处理常用的技术 但 Hadoop NoSQL 和多接点的特点 为应用开 发和平台维护带来一定的难道 通过技术服务 对 Hadoop 应用开发提供参考标准和技术 支持 研究并制定 Hadoop 平台的维护标准 1 21 2目的目的 1 形成对网管数据地图与数据模型标准的梳理 作为在建数据共享中心的规范与指导 2 研究海量数据的处理与分析技术 模式 为后续进一步建立针对大数据的数据共享中 心提供可行方案与指导 为了达到上述目标 本项目分解为四个子项目 各子项目工作内容如下 1 1 网络数据地图研究子项目网络数据地图研究子项目 对现有网管数据从生产到消费的全流程梳理 形成网管数据血缘关系和数据地图 以作为网管数据统一建模 集成共享的基础 2 2 网络数据共享模型标准研究子项目网络数据共享模型标准研究子项目 根据数据地图 建立可扩展的 面向底层数据源和上层应用灵活适配的网管数据 模型 作为数据共享中心模型标准 3 3 网络数据共享技术标准子项目网络数据共享技术标准子项目 研究海量数据共享技术和模式 对数据库共享 数据编排 服务共享等数据共享 技术和模式进行评估 制定符合网络数据中心的共享技术标准 4 4 网络数据共享平台维护标准子项目网络数据共享平台维护标准子项目 数据共享平台采用 Hadoop 架构 多种技术共存 方案相对复杂 NoSQL 和多节 点的特点 为应用开发和平台维护带来一定的难道 通过技术服务 对应用开发 提供参考标准和技术支持 研究并制定平台的维护标准 1 31 3范围范围 该文档是用于指导贵州移动网络共享平台 HBASE 安装部署 参数设置 备份 恢复 监控的规范 可编辑修改 2 2硬件准备硬件准备 设备用途设备用途 操作操作 系统系统 设备设备 数量数量 设备设备 数量数量 主机名主机名 IPIP 说明说明 2 CXNDSP HDP 01 CXNDSP HDP 02 控制服务器 Hadoop 服务器 Centos6 2 Centos6 2 16 14 CXNDSP HDP 03 CXNDSP HDP 04 CXNDSP HDP 16 数据节点 3 3实施实施 3 13 1软件准备软件准备 HADOOP 软件已经正确安装完成 3 23 2HBASEHBASE 服务器规划服务器规划 Hadoop 版本 hadoop 1 2 1 Hbase 版本 hbase 0 94 19 zookeeper 版本 hbase 自带 主机名HADOOP 功能Hbase 功能zookeeper 功能 CXNDSP HDP 01Master NameNodeMasterHQuorumPeer CXNDSP HDP 02Slave DataNodeDataNodeHRegionServer CXNDSP HDP 03Slave DataNodeDataNodeHQuorumPeer HRegionServer CXNDSP HDP 04Slave DataNodeDataNodeHQuorumPeer HRegionServer CXNDSP HDP 05Slave DataNodeDataNodeHQuorumPeer HRegionServer CXNDSP HDP 15Slave DataNodeDataNodeHQuorumPeer HRegionServer CXNDSP HDP 16Slave DataNodeDataNodeHQuorumPeer HRegionServer 3 33 3HBASEHBASE 安装安装部署部署 1 1 hbasehbase 软件下载软件下载 官网 http www apache org dyn closer cgi hbase 下载当前稳定版 hbase 0 94 19 tar gz 2 2 下载后解压到下载后解压到 HADOOPHADOOP 系统用户下系统用户下 opt cloud opt cloud hbase 0 94 19hbase 0 94 19 可编辑修改 3 3 配置配置 文件文件 1 1 hbase env shhbase env sh 主要修改 a JAVA 环境配置 export JAVA HOME usr java jdk1 6 0 45 b HBASE CLASSPAT 利于 Hbase 与 Hadoop 关联 export HBASE CLASSPATH opt cloud hadoop 1 2 1 conf c c 设置使用设置使用 HbaseHbase 自带自带 ZOOKEEPERZOOKEEPER export HBASE MANAGES ZK true d 参考 hbase env sh 配置文件配置文件 2 2 hbase site shhbase site sh a hbase rootdir 这个目录是 region server 的共享目录 用来持久化 HBase 需要先创建该目录 hadoop fs mkdir hdfs CXNDSP HDP 01 9000 hbase b distributed 是指定开启集群分布式 true 为开启 c master 是指定 master 的机子和端口 d quorum 是指定放 zookeeper 机子 被指定的机器上会运行 HQuorumPeer 进程 e dataDir 是指定临时目录 建议为 hadoop tmp dir hbase f 参考 hbase site xmlhbase参数 htm 配置文件配置文件 3 3 regionserversregionservers a HregionServer 节点 配置为 hadoop 的 datanode 节点即可 4 4 驱动包驱动包 因为 Hbase 与 Hadoop 有版本支持对应关系 所以要将 Hadoop 根目录下的驱动包 放到 Hbase 的 lib 目录 同时删除 Hbase 的 lib 下的旧版本的 hadoop core 包 将 可编辑修改 覆盖到 5 5 安装到其他节点安装到其他节点 将当前配置好的 Hbase 同步到其他节点机 scp r opt cloud hbase 0 94 19 hadoop CXNDSP HDP 02 opt cloud scp r opt cloud hbase 0 94 19 hadoop CXNDSP HDP 03 opt cloud scp r opt cloud hbase 0 94 19 hadoop CXNDSP HDP 04 opt cloud scp r opt cloud hbase 0 94 19 hadoop CXNDSP HDP 15 opt cloud scp r opt cloud hbase 0 94 19 hadoop CXNDSP HDP 16 opt cloud 6 6 启动启动 HBASE HBASE Bin Start hbase sh 启动完成后 JPS 查看进程 可编辑修改 也可网页浏览 http 172 17 1 1 60010 master status 7 7 进入 进入 HbaseHbase shellshell 安装成功 安装成功 可编辑修改 3 43 4H HBASEBASE 参数配置参数配置 时钟同步 所有节点机一定要时钟同步 如果不用 NTP 做时钟同步 可能无法启动 Hbase 的 HregionServer 进程 ROOT 用户环境变量 etc profile 增加 生效 sourcesource etc profile etc profile 同步到其他几点机 HADOOP 用户环境变量 home hadoop bash profile home hadoop bash profile 增加 增加 环境配置环境配置 参考 1 首先配置 HADOOP HOME 下的 conf hadoop env shconf hadoop env sh 文件 修改其中的 HADOOP CLASSPATH 增加 HBASE 的相关 lib 包环境 如下 export HADOOP CLASSPATH HADOOP CLASSPATH opt cloud hbase 0 94 19 hbase 0 94 19 jar opt cloud hbase 0 94 19 hbase 0 94 19 tests jar opt cloud hbase 0 94 19 lib guava 11 0 2 jar opt cloud hbase 0 94 19 lib zookeeper 3 4 5 jar opt cloud hbase 0 94 19 conf 2 配置 HADOOP HOME 下的 conf core site xmlconf core site xml 加入如下信息 hbase zookeeper quorum CXNDSP HDP 01 CXNDSP HDP 03 CXNDSP HDP 04 CXNDSP HDP 05 CXNDSP HDP 06 3 配置 HBASE HOME 下的 conf hbase env shconf hbase env sh 修改其中的 HBASE CLASSPATH 为如下 4 重启 hbase 和 hadoop 先停 hbase stop hbase sh 再停 hadoop stop all sh 先启 hadoop start all sh 可编辑修改 再启 hbase star hbase sh 案例测试 使用案例测试 使用 importtsvimporttsv 加载加载 HDFSHDFS 文件为文件为 HFILEHFILE 给 hdfs 上传待导入 hbase 的数据文件 t8 txt 在 hbase 中创建表 t8 create t8 f1 在 hbase 中创建表 t8 在 HADOOP HOME 下执行 二级列名可自定义 分隔符如果不是空格要 指明 hadoop jar HBASE HOME hbase 0 94 19 jar importtsv Dimporttsv columns HBASE ROW KEY f1 a a f1 b b f1 c c Dimporttsv separator t8 data01 work Yang 查询表 3 53 5H HBASEBASE 备份恢复备份恢复 3 5 13 5 1常用的在线备份方案及其比较常用的在线备份方案及其比较 对于数据中心的数据冗余的备份方案 目前从一致性 事务性 延迟 吞吐量 数据 损失 Failover 几个角度来分析有一下几种方案 简单备份模式通过定时不定时的 Dump 出集群数据保证数据的安全性 通常可以通过 snapshot 或设置时间戳来 dump 数据来实现这种方案 如果方案简介 设计优雅可以做到对 在线数据中心低干扰或无干扰的数据备份 但这种方案缺点也是显而易见的 只是对时间 点之前的数据安全性得到保障 如果发生突发事件会导致不可避免的整段时间的数据丢失 为很多人无法接受 主从模式 Master Slave 这种模式比起简单的备份模式多了很多优点 可以通过最终 一致性保证数据的一致 数据从主集群到备集群延时较低 异步写入不会对主集群带来性 能压力 基本不会产生多少性能的影响 突发事件来临时数据丢失很少 并且主集群的事 务在备集群也可以得以保证 一般通过构造较好的 Log 系统加上 check Point 来实现 可以 实现读写分离 主集群可以担当读写服务 但备集群一般只承担读服务 可编辑修改 主主模式 Master Master 原理总体类似于主从模式 不同的是 2 个集群可以互相承担 写的分离 都可承担读写服务 2 阶段提交这种方案保证了强一致性和事务 服务器返回给客户端成功则表明数据一 定已经成功备份 不会造成任何数据丢失 每台服务器都可承担读写服务 但缺点是造成 集群延迟较高 总体吞吐下降 Paxos 算法基于 Paxos 算法的实现的强一致性方案 同一客户端连接的 server 能保证数 据的一致性 缺点是实现复杂 集群延迟和吞吐随着集群服务器增加而边差 我们可以通过下面的一个图标来说明简化一下上面各种模式的特点 备份主从主主 2PCPaxos 数据一致性差保证最终一致性强一致性 事务无主集群保证分别保证主集群保证主集群保证 延迟低低低高高 吞吐量高高高低低 数据丢失大量最近短暂时间丢失最近短暂时间丢失无丢失无丢失 集群服务无服务主读写从只读读写读写读写 Hbase Replication 主从模式通过指定备集群 将 Hlog 里面的数据异步发送到备集群 对主集群基本没有性能影响 数据延时时间较短 主集群提供读写服务 备集群提供读服 务 如果主集群有故障 可以快速切换到备集群 回过头来我们可以看看 Hbase 的备份状 况 Hbase 可以同过离线备份和在线备份提供上述的简单备份模式 主从和主主三种备份 模式模式 Hbase 简单备份模式如果表不在线比较好办 可以通过 copy table 或者是 distcp add table 来解决 如果表在线并且不能让其下线 只有通过 snapshot 方案对 online 的 table 实施 备份 关于 snapshot 原理我发另一篇文章来解释 Hbase Replication 主主模式 2 个集群互为主备 都提供读写服务 读写分离 通过比较 总体看来 hbaseReplication 的解决方案可以很好的解决集群安全性 数据安全性 读写分离 运维和客户操作失误等等的问题 并且易于管理和配置 为在线应用提供强有力的支持 3 5 23 5 2原理原理 3 5 2 13 5 2 1ReplicationReplication 总体结构总体结构 Replication 的总体架构比较简单 我们直接引用社区的架构图来说明 主集群的 hlog 中记录了所有针对 table 的变更 目前的 ddl 不同步 通过实时读取 hlog 中的 entry 来解 析变更的数据然后发送到从集群中去 可编辑修改 可编辑修改 3 5 2 23 5 2 2ReplicationReplication 工作流程工作流程 可编辑修改 3 5 2 33 5 2 3ReplicationReplication ClassClass 简介简介 ReplicationSourceManager Master 的 replication 线程主要管理者 负责初始化 启动或 结束线程 同时也会 watch 主集群的 ZK 上 RS 节点在有 RS 退出或加入是时立即 failover 保证数据的无丢失 ReplicationZooKeeper 用于控制和管理 replication 在 Zookeeper 上的一系列操作 ReplicatioSource replication 工作线程 负责读取 解析 发送和记录 Hlog ReplicationLogCleanner 管理 Replication 时的 hlog ReplicationSink 备集群用于接收主集群的 hlog entry 后 分析并写入本集群 NodeFailover 处理节点退出后为处理完的 hlog ZKWatcher watch replication 对应的 zk 节点 并启动对应的任务 可编辑修改 3 5 2 43 5 2 4ReplicationReplication ZookeeperZookeeper 上的结构上的结构 Peer 节点 管理 slave 集群在 zk 上的配置 State 节点 记录 replication 运行的状态 Rs 节点 记录着本集群 Rs 中对应的 hlog 同步的信息 包括 check point 信息 可编辑修改 3 5 2 53 5 2 5ReplicationReplication FailoverFailover Hbase Replication 在 replication 时 我们通常会遇到主集群和备集群的 RS 预料之中或者 预料之外的上线下线 在发生这种情况的时候 必须设计出一种稳定合理的并且有迭代功 能的 Failover 处理机制来保证数据不会丢失 我们可以分别分析主从集群遇到这种情况时 Failover 的处理方案 主集群 RS 加入 zk 会迅速 watch 到 rs 节点的创建 创建出新的 replication source 线 程来处理新加入到 hlog 主集群 RS 退出 这是最为复杂的一种情况 主要是退出的 RS 会有一部分的 hlog 没有处理完 需要稳定的 shift 到其他 RS 上 我们可以从下面三个步骤说明 集群正常工作时 ZK 的状态如下 可编辑修改 这是 1 1 1 2 这台 RS 突然下线 ZK 会第一时间 watch 到这个动作 最先发现的集群中 的某台 1 1 1 3 rs 将其在 Replication rs 下对应的 lock 住 并将其考到自己的节点之下 其他的 RS 1 1 1 1 发现其被 lock 后就不做动作 1 1 1 3 启动一个新的线程处理掉所有未被同步的 hlog 保证数据不丢失 同理如果 1 1 1 3 此 时再次下线 zk 节点被迭代拷贝 可编辑修改 备集群 RS 加入 不影响主集群的步骤 region 均匀的话客户端会自动写入到新加入 到集群之中 备集群 RS 退出 主集群在重试几次后发现对方 down 机 将其加入到 deadserver 的 列表之中 后续不会被 Call 3 5 33 5 3部署部署 Hbase 的部署详细步骤如下 3 5 3 13 5 3 1MasterMaster 集群配置文件集群配置文件 html html view plaincopyprint 可编辑修改 1 2 hbase replication 3 true 4 打开 replication 功能 5 6 7 replication source nb capacity 8 5000 9 主集群每次像备集群发送的 entry 最大的个数 推荐 5000 可根据集群 规模做出适当调整 slave 集群服务器如果较多 可适当增大 10 11 12 replication source size capacity 13 4194304 14 主集群每次像备集群发送的 entry 的包的最大值大小 不推荐过大 15 16 17 replication source ratio 18 1 19 主集群里使用 slave 服务器的百分比 20 21 22 hbase regionserver wal enablecompression 23 false 24 主集群关闭 hlog 的压缩 25 26 27 replication sleep before failover 28 5000 29 主集群在 regionserver 当机后几毫秒开始执行 failover 30 3 5 3 23 5 3 2SlaveSlave 集群配置文件集群配置文件 html html view plaincopyprint 1 可编辑修改 2 hbase replication 3 true 4 打开 replication 功能 5 3 5 3 33 5 3 3MasterMaster 集群配置集群配置 修改好 Master 集群配置文件 关联 replication Master 和 Slave 集群 在 master hbase shell 中做以下操作 Addpeer hbase add peer 1 zk1 zk2 zk3 2182 hbase prod zk 的地址 端口 和 Slave 的 zk address Start replication 标志 hbase start replication add peer 和 start replication 标记是直 接修改 zk 上的 node 所以不需要启动集群做这个动作 3 5 3 43 5 3 4SlaveSlave 集群配置集群配置 修改好 Slave 集群配置文件 并启动 slave 集群 根据需要在 Slave 中创建需要同步的 table 注意每个 CF 的 KEEP DELETED CELLS true 属性要打开来保证为写入的顺序性 hbase disable peer 1 b 重新服务 hbase enable peer 1 c 停止服务 hbase stop replication 3 63 6H HBASEBASE 监控监控 hbase 进程层面上数据的监控 主要分为以下几部分 hbase 监控的配置说明 hadoop 基于 ganglia 的 metric 监控框架 hbase 中 regionserver 上 RPC 的监控数据计算采集 regionserver 中 jvm 监控数据的计算采集 regionserver 进程状态监控数据的计算采集 可编辑修改 3 6 13 6 1hbasehbase 的监控配置说明的监控配置说明 在 hbase 的 conf 目录下 hadoop metrics properties 文件中 对于 hbase 进程层面上数据 jvm rpc 等 的采集进行配置 主要是配置采集数据时使用的对象 采集的频率 采集 数据的接收 gmond 进程 例如对于 RPC 的配置 rpc class org apache hadoop metrics ganglia GangliaContext31 rpc period 10 rpc servers 192 168 0 100 8649 rpc class 选择 hadoop 中的 GangliaContext31 类 这个类主要负责监控数据的打包和发送 rpc period 默认为 10 秒 即 10 秒采集发送一次数据 rpc servers 配置指定了一台接受 GangliaContext31 类发送的监控数据 目前集群中 ganglia 采用单播的方式收集数据 一个集 群内会指定一台机器上的 gmond 进程来专门接受集群内所有机器发来的监控数据 这个集 群内负责接收数据的机器 ip 是 192 168 0 100 机器上的 gmond 进程端口是默认的 8649 当然 还可以配置 rpc class 为 org apache hadoop hbase metrics file TimeStampingFileContext 以本地文件的方式来存储监控 数据 这个就略去了 在每个 hbase 集群内 会选择一台机器上的 gmond 进程来接受集群内其他机器上 gmond 发送来的监控数据 我们称之为主 gmond 在 hbase 监控系统所在机器上运行 gmeta 进程 负责从每个 hbase 集群内的主 gmond 上拉取数据到本地 最终为被监控系统所访问 这是一个典型的多集群使用 ganglia 来构建监控系统的架构 3 6 23 6 2hadoophadoop 基于基于 gangliaganglia 的监控框架的监控框架 下面以 regionserver 进程来简单描述下 hbase 内部采集 metric 的过程 master 的进程中 的过程基本类似 采集的数据略有区别 在 hbase 的 HRegionServer 类 regionserver 进程的类 中 成员变量 server 是 HBaseServer 实例 在 server 对象中 rpcMetrics 变量在初始化的时候 会采用反射机制的方 式 来创建一个负责发送监控数据的对象 该对象的类名称就是前面提到的配置文件中 rpc class 中指定的 org apache hadoop metrics ganglia GangliaContext31 在构造该对象的时候 也指定了发送数据的时间间隔是 10 秒钟 rpcMetrics 主要负责处理 rpc 相关的信号数据的 采集 负责采集 jvm 和 regionserver 的 metric 的对象的构造基本上和 rpcMetrics 相同 只是 阶段不同 前者是在 HRegionServer 对象构造的时候创建的 后两者是在 HRegionServer 类 的对象运行 run 方法的时候构造的 以 rpcMetrics 为例 该变量是一个 HBaseRpcMetrics 类的对象 负责采集 regionserver 的 metric 采集的类是 RegionServerMetrics 负责 jvm 的是 JvmMetrics HBaseRpcMetrics 对 象在初始化的时候 会根据根据配置 使用反射机制来创建一个 GangliaContext31 的对象 可编辑修改 并将数据的发送间隔设置为配置中指定的 10 秒 如果没有配置 则默认 5 秒 在构造完 GangliaContext31 对象后 会调用 startMonitoring 方法 该方法实际上位于 GangliaContext31 继承的 AbstractMetricsContext 中 startMonitoring 方法中会构造一个异步执行的定时任务 该定时任务主要通过 timerEvent 接口来实现 该接口主要负责调用在 AbstractMetricsContext 中注册的各个 updater 来获取各个 updater 的监控数据 并打成固定格式的 UDP 包 发送 给指定的 gmond 进程 在完成了 GangliaContext31 的对象的构建后 会通过 GangliaContext31 的对象将自身作为一个 updater 注册到 AbstractMetricsContext 中 最后 调 用 HBaseRpcMetrics 中的 initMethods 方法 为所有的 RPC 接口生成生成 MetricsTimeVaryingRate 对象 以对应的 RPC 接口的名称为 key 以 MetricsTimeVaryingRate 对象存入一张 hash 表中 这样 就完成了 HBaseRpcMetrics 类的对象的初始化 HBaseRpcMetrics 类的对象会作为一个 updater 注册到 AbstractMetricsContext 中 被定时 调用 这个调用的接口就是 doUpdates 这个接口负责实现对 RPC 中各个 MetricsTimeVaryingRate 对象推送到 GangliaContext31 的对象缓冲 hash 表 中 HBaseRpcMetrics 类实现了 Updater 抽象类中的 doUpdates 接口 在 regionserver 运行的过程中 当某个 hanler 线程处理 RPC 的时候 会调用 HBaseRpcMetrics 中的 inc 方法 该方法的参数是 RPC 的名称和 RPC 的处理时间 该方法 根据参数 找到 RPC 对应的 MetricsTimeVaryingRate 对象的 inc 方法来将 PRC 的处理时间增 加 并加 RPC 请求的数量自增 1 次 上面简单描述了 HBaseRpcMetrics 对象的初始化 采集和 rpc 相关的 metric 以及推送 metric 的过程 简单的说来 RegionServerMetrics 以及 JvmMetrics 和 HBaseRpcMetrics 相比 在后台推送监控数据的框架基本一致 区别在于这两个类在采集监控数据的流程 3 6 33 6 3hbasehbase regionserverregionserver 中中 RPCRPC metricmetric 的计算采集的计算采集 Hbase 中统计 RPC 的数据较为简单 主要是统计在两次发送间隔内的 RPC 的请求的数 量以及平均请求的处理时间 前面提到的 HBaseRpcMetrics 类的对象负责采集这些 metric RPC 统计主要是 HMasterInterface HMasterRegionInterface HRegionInterface HBaseRPCErrorHandler 和 OnlineRegions 这五个接口中声明的方法 对于每个方法 采用了一个 MetricsTimeVaryingRate 对象来存储数据 这些对象和方法名称作为 hash 的 value 和 key 存入 HBaseRpcMetrics 中的一张 map 对象中 在 regionserver 的 handler 线程调用 RPC 时 会记录调用前后花费的时间 将花费的时 间存储到对应的 MetricsTimeVaryingRate 对象 这个操作会更新 MetricsTimeVaryingRate 对象 中两个成员变量 这两个成员变量记录了从某个时间点 上次发送数据给 gmond 的时间 以来所接受的请求次数和处理请求的累积时间 每隔 10 秒 当前配置文件中指定的发送数据的时间间隔是 10 秒钟 HBaseRpcMetrics 可编辑修改 中的 doUpdates 方法会被 GangliaContext31 父类中的定时任务调用 来将当前统计的数据推 送到缓冲区中 HBaseRpcMetrics 中的 doUpdates 方法主要是将每个 MetricsTimeVaryingRate 对象中累积的处理时间除以累积的处理次数 来获得该 RPC 的平均处理时间 将平均的处 理时间和累积的操作次数推送到 GangliaContext31 父类的缓冲区中 然后将累积的处理时间 和累积处理次数这两个变量重置 来准备下个固定时间间隔内的数据采集 对于 RPC 的统计来说 监控数据的采集和推送是两个异步的过程 在 gmeta 的进程所在机器上 在 gmetad 配置文件的配置项 rrd rootdir 所指定的目录下 可以看到每个 hbase 集群都有一个相应的目录 目录下有各个机器对应的子目录 可以在 各个机器的子目录下看到各个 RPC 的 RDD 文件 例如 对于 checkAndPut 请求 存在 rpc metrics checkAndPut num ops rrd 和 rpc metrics checkAndPut avg time rrd 文件 存储了该 机器上 checkAndPut 请求数量和处理平均时间 可以通过 rrdtool dump file name 来简单的查 看监控数据 RPC 的监控项的数据 主要存储在 ganglia 数据目录的某个主机名做目录名称的子目录 下 以 rpc metrics 为前缀的 rrd 文件中 主要对某个 RPC 请求的次数以及平均操作时间的 统计 下面是对 RPC 相关的监控项的说明 metric rrd 文件含义 rpc metrics R avg time rrd 在固定间隔内 R 的平均操作时间 rpc metrics R num ops rrd 在固定间隔内请求 R 的次数 rpc metrics RpcQueueTime avg time rrd RPC 在 call 队列中等待平均时间 rpc metrics RpcQueueTime num ops rrd RPC 在 call 队列中等待的数量 rpc metrics RpcProcessingTime avg time rrd 平均处理一个 RPC 所消耗时间 rpc metrics RpcProcessingTime num ops rrd 实际处理 RPC 的数量 3 6 43 6 4hbasehbase 中中 JVMJVM 监控数据的计算采集监控数据的计算采集 Hbase 中对于 JVM 的监控数据 主要是 JvmMetrics 的对象来进行的 该对象在 HRegionServer 的 run 方法中被实例化 JvmMetrics 主要统计的信息包括 内存的使用状态信息 GC 的统计信息 线程的统计 信息 以及事件的统计信息 内存的统计信息主要是 JVM 当前已经使用的 NonHeapMemory 的大小 以及配置的 NonHeapMemory 的大小 JVM 当前已经使用的 HeapMemory 的大小 以及配置的 HeapMemory 的大小 已经 JVM 运行时的可以使用的最大的内存的大小 内存的统计信息 主要借助 JVM 的接口来获得 这些数据均以兆为单位发送到 gmond 中 GC 的统计较为简单 仅统计了进程在固定间隔内 GC 的次数和花费的总时间 线程的统计 主要是统计进程内当前线程的处于 NEW RUNNABLE BLOCKED WAITING TIMED WAITING TERMINATED 这六种状 态下的线程数量 可编辑修改 对于事件的统计 主要统计固定时间间隔内的 Fatal Error Warn 以及 Info 的数量 由于这部分需要采集的数据较少 JVM 中数据的采集和推送都是由 GangliaContext31 父类中的定时任务调用 doUpdates 来完成的 并不像 RPC 那样分作两个异步的阶段来进行 同样地 对于 JVM 的监控数据 存储在对应的主机目录下 以 jvm metrics 为前缀的 rrd 文件中 下面是对监控项的说明 metric rrd 文件说明 jvm metrics gcCount rrd JVM 进行 GC 的次数 jvm metrics gcTimeMillis rrd GC 花费的时间 单位为微妙 jvm metrics logError rrd Log 中输出 ERROR 的次数 jvm metrics logFatal rrd Log 中输出 FATAL 的次数 jvm metrics logInfo rrd Log 中输出 INFO 的次数 jvm metrics logWarn rrd Log 中输出 WARN 的次数 jvm metrics maxMemoryM rrd JVM 最大的可用内存大小 单位 M jvm metrics memHeapCommittedM rrd JVM 分配的堆大小 单位 M jvm metrics memHeapUsedM rrd JVM 已经使用的堆大小 单位 M jvm metrics memNonHeapCommittedM rrd JVM 分配给非堆的大小 单位 M jvm metrics memNonHeapUsedM rrd JVM 已使用的非堆的大小 单位 M jvm metrics threadsBlocked rrd 处于 BLOCKED 状态线程数量 jvm metrics threadsNew rrd 处于 NEW 状态线程数量 jvm metrics threadsRunnable rrd 处于 RUNNABLE 状态线程数量 jvm metrics threadsTerminated rrd 处于 TERMINATED 状态线程数量 jvm metrics threadsTimedWaiting rrd 处于 TIMED WAITING 状态线程数量 jvm metrics threadsWaiting rrd 处于 WAITING 状态线程数量 3 6 53 6 5hbasehbase 中中 regionserverregionserver 进程相关进程相关 metricmetric 的计算采集的计算采集 Regionserver 的进程监控数据主要由 RegionServerMetrics 的实例来负责 主要采集的数 据包括 一 region 的信息 上线 region 数量 store 的数量 storefile 的大小 storefileindex 的 大小 读取时 memstore 命中的次数和缺失次数 二 blockcache 的信息 例如 blockcache 中使用多少 空闲多少 累计的缺失率 命 中率等 三 读写请求的统计信息 例如最大最小读写响应时间 读写的表分布 来源 ip 分 布 读写数据量 读写失败次数等 四 dfs 操作的信息 例如读写延迟 sync 延迟 flush 时间和大小 hlog 的写入时间 次数等 五 compact 与 split 的操作信息 例如队列的长度 操作次数和时间等 六 handler 的信息 例如队列长度 处于活跃 handler 的数量以及活跃的 reader 数量 可编辑修改 监控数据的采集和推送分为两个异步的过程来进行 由 GangliaContext31 父类中的定时 任务调用 doUpdates 来完成数据的推送 Regionserver 的 run 方法中在固定间隔时间内来调 用 doMetrics 来进行数据的采集 3 6 5 13 6 5 1regionregion 的的 metricmetric 采集采集 目前 在 hbase 中 region 和 storefile 的信息都存储在类 HRegionServer 的成员 onlineRegions 该成员是一个 hash 表的实例 具体为实例为 ConcurrentHashMap key 是 region 的名称 主要存储了上线的 region 的数量 region 使用的 memstore 的大小 store 的大小 storefile 的数量 storefile 的索引使用的内存大小 在进行 打开或是关闭 region 这类操作时 都会及时更新 onlineRegions 中相关的信息 具体的流程 可以查看代码 这些信息的统计过程较为简单 主要是访问 onlineRegions 通过该 hash 表的 size 接口 可以获得当前上线的 region 的数量 然后遍历 onlineRegions 中的每个 HRegion 对象 获得 每个 HRegion 的 memstore 的大小 进行累积 接着遍历 HRegion 中的每个 store 的大小 获取每个 store 中 storefile 数量 以及使用索引内存的大小 进行累积 完成遍历制后 就 获得了上线的 region 数量 memstore 使用的内存大小 store 的数量 storefile 的数量 storefile 的索引使用的内存大小 最后 memstore 使用的内存大小和 storefile 的索引使用的内 存大小都是以兆为单位发送给 g