能够对整个集群有一个比较详细的状态监控,如

程序员也能玩转的集群监控,程序员也能集群监控

点击上方蓝字进行关注的都是靓仔和仙女

为什么需要监控?

为了保证系统的稳定性,可靠性,可运维性。

  • 掌控集群的核心性能指标,了解集群的性能表现;

  • 集群出现问题时及时报警,便于运维同学及时修复问题;

  • 集群重要指标值异常时进行预警,将问题扼杀在摇篮中,不用等集群真正不可用时才采取行动;

  • 当集群出现问题时,监控系统可以帮助我们更快的定位问题和解决问题。

如何构建 HBase 集群监控系统?

公司有自己的监控系统,我们所要做的就是将 HBase 中我们关心的指标项发送到监控系统去,问题就转换为我们开发,采集并返回哪些 HBase 集群监控指标项。

HBase 集群监控指标

采集的监控数据主要包括以下几个方面:某台机器 OS 层面上的数据,例如 CPU、内存、磁盘、网络、load、网络流量等;某台 regionserver(或master)机器 jvm 的状态,例如关于线程的信息,GC 的次数和时间,内存使用状况,以及 ERROR、WARN、Fatal 事件出现的次数;regionserver(或 master)进程中的统计信息。

可以通过以下地址获取 HBase 提供的 JMX 信息的 web 页面

JMX web 页面的数据格式是json格式,信息很多!

OS 监控数据

HBase 中对于 OS 的监控数据,主要是 OperatingSystem 的对象来进行的,如下就是我提取出来的 JSON 信息。

其中比较重要的指标有 OpenFileDescriptorCount , FreePhysicalMemorySize , ProcessCpuLoad , SystemCpuLoad , AvailableProcessors , SystemLoadAverage

JVM 监控数据

Hbase 中对于 JVM 的监控数据,主要是 JvmMetrics 的对象来进行的,如下就是我提取出来的 JSON 信息,

JvmMetrics 主要统计的信息包括:内存的使用状态信息;GC的统计信息;线程的统计信息;以及事件的统计信息。

内存的统计信息主要是:JVM 当前已经使用的 NonHeapMemory 的大小、以及配置的 NonHeapMemory 的大小;JVM 当前已经使用的 HeapMemory 的大小、以及配置的 HeapMemory 的大小; JVM 运行时的可以使用的最大的内存的大小。

GC 的统计较为简单,仅统计了进程在固定间隔内 GC 的次数和花费的总时间。

线程的统计,主要是统计进程内当前线程的处于 NEW 、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED 这六种状态下的线程数量。

对于事件的统计,主要统计固定时间间隔内的 Fatal、Error、Warn 以及 Info 的数量。(这块好像不怎么重要)

REGION SERVERS 健康

你也可以通过如下地址:

获得到 Region Servers 健康值:

MEMORYPOOL

从全部的 JSON 值中你会看到很多种 MemoryPool 值,比如 Par Eden Space 、CMS Perm Gen、Par Survivor Space、CMS Old Gen、Code Cache ,按需获取吧。

总结

任何一个服务的监控系统都是一个不断迭代,不断优化的过程,不可能一开始就做到最好。监控总是比问题发生来的更早一些,而每一次出问题,又进一步加强相应方面的监控,我们需要让监控系统从出问题时才报警到可能出现问题时就预警逐渐过渡,最终让监控系统成为我们保证系统稳定性的一个有力工具。

想更加详细,更加深入的了解集群其它方面的内容吗?

在这里部落告诉大家一个小秘密

今晚8:30

动脑学院  Five大神

将在腾讯课堂  动脑学院  免费Java公开课中

给大家详细讲解

《 分布式、集群环境互联网系统订单号生成策略 》

你只需要在今晚8:30的时候

点击文章最末 阅读原文

即可进行观看

推荐阅读  

高并发与分布式系统的基石--数据库读写分离实战

这就是学编程的下场...

论程序员与产品经理是怎么互掐起来的

如何假装成为一名好的程序员

来自部落的邀请

Java框架 Spring 核心机制

至程序员的情书

Java高级部落送你ofo小黄车60天免费骑行,还不来?

Facebook研发的Cassandra你用过吗?

给 Java开发者的10个大数据工具和框架

推荐程序员必备微信号 

说到对Hadoop和HBase的集群监控,大家知道的和用的最多的可能还是第三方的监控工具,cacti,ganglia,zabbix之类的。玩的深一些的,会用zenoss之类的。这些工具确实不错,也能发挥很大的作用,但时间长了总感觉监控粒度还是比较粗,不够详细。毕竟是第三方的监控,即便Hadoop自带了ganglia的接口,也还是觉得不够。

使用jdk的jconsole进行监控jmx

首先,设置监控对象的端口   配置 catalina.sh

  #vi /usr/tomcat/bin/catalina.sh

      注: /usr/tomcat/bin/catalina.sh 是 tomcat所在目录的bin目录  (linux环境下)

在 # OS specific support.  $var _must_ be set to either true or false.之前添加内容

 

# JAVA_OPTS 设置内存

JAVA_OPTS="-Xms2g -Xmx2g -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:NewSize=512m -XX:MaxPermSize=256m"

 

# CATALINA_OPTS 设置 jmx端口信息

CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote  -Dcom.sun.management.jmxremote.port=9004"

CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

 

然后,启动对应的tomcat,查看端口运行

  [root@css ~]# netstat -antp | grep 9004
  tcp 0 0 :::9004 :::* LISTEN 2288/java

最后,确认本地jdk已安装,没有安装的自行安装

  打开cmd,运行进入目录:C:Program FilesJavajdk1.6.0_43bin

    C:Usersshuaiqi>cd /d C:Program FilesJavajdk1.6.0_43bin

  执行jconsole.exe文件

    C:Program FilesJavajdk1.6.0_43bin>jconsole.exe

  此时就已经打开了,链接jmx的方式

  可以选择本地进程和远程进程,这里选择远程进程

  输入远程地址:<hostname>:<port> 点击链接按钮即可链接

  注:不需要输入用户和口令,因为上述设置中没有要求用户和口令,如有需要可以设置一下

 

其实Hadoop本身是带有监控接口的,各公司的发行版还有自己定制的接口,不过可能知道的人就不太多了。这个不详细的看文档和源码一般是找不到的,属于隐藏属性。事实上,我写的EasyHadoop管理界面里面就用到了这个监控的接口,能够对整个集群有一个比较详细的状态监控,目前还在不断扩展。下一步会实现对Java进程的Heap使用的监控,这样对整个集群的性能调优就会起到比较重要作用。

jvm 内存持续增长

  原因:内存池“par survivor space” 与 内存池“cms old gen” 持续交换内存,导致原因是 因为内存池“par eden space”不够大导致交换区内存持续饱满状态
  解决:修改tomcat_home/bin/catalina.sh 调整内存比例 4:1 实际到内存中即3:1
  # JAVA_OPTS
  JAVA_OPTS="-Xms4g -Xmx4g -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:NewSize=1024m -XX:MaxPermSize=256m"

 

其实这个接口特别简单,但是非常详细,也非常方便,就是JMX。

监控详解

在启动的界面中:
1.概述:有关堆内存使用情况,线程,类加载和CPU使用情况的综述;
2.内存:内存的详细情况,堆和其他内存;
3.线程:峰值/活动线程,另外,各个线程的明细信息,检测死锁;
4.类:监控加载和卸载的类,这个需要结合其他的工具进行分析;
5.MBean:当前Java程序的MBean(如果有的话)的操作;
6.VM摘要:有关JVM的明细信息;

从概要中我们可以直观的了解系统运行的总时间、线程数、内存与垃圾回收信息、装载类及操作系统内存的信息。
其中内存的信息对应我们配置的-Xms256m -Xmx512m
垃圾收集器对应我们配置的垃圾回收方式,每种方式的名称会有所不同,当我们没有配置垃圾回收方式时一般为UseParallelGC这种方式
(1)-XX:+UseConcMarkSweepGC 并行的CMS垃圾回收方式
GC名: ParNew
ConcurrentMarkSweep
内存池名: CMS Perm Gen Par Eden Space Par Survivor Space Code Cache CMS Old Gen
(2)-XX:+UseParallelGC 并行垃圾回收
GC名: PS Scavenge PS MarkSweep
内存池名: PS Survivor Space PS Perm Gen PS Old Gen PS Eden Space Code Cache
(3)-XX:+UseParallelOldGC 并行垃圾回收
GC名: PS Scavenge PS MarkSweep
内存池名: PS Survivor Space PS Perm Gen PS Old Gen PS Eden Space Code Cache
(4)-XX:+UseSerialGC 串行垃圾回收
GC名: Copy MarkSweepCompact
内存池名: Survivor Space Perm Gen Tenured Gen Eden Space Code Cache

 

Hadoop的http监控端口基本所有人都知道,namenode 50070,jobtracker 50030,datanode 50075,tasktracker 50060。不过当用户访问这些端口的时候,会自动跳转到dfshealth.jsp或者jobtracker.jsp这样的监控页面。jmx的访问很简单,只需要把网页的名字换成jmx就可以了。

右下方蓝色显示条

年轻代:PS Eden Space和PS Survivor Space
对应配置参数:-Xmn256M -XX:MaxNewSize=256M -XX:SurvivorRatio=2 -XX:MaxTenuringThreshold=5等
老年代:PS Old Gen 其值是:Old = Heap - Young={Eden,from,to}
对应配置参数包括:-Xms512m -Xmx1024m和年轻代的配置参数,from,to的值取决于SurvivorRatio这个参数的设置
持久代:PS Perm Gen
对应的配置参数:-XX:PermSize=256M -XX:MaxPermSize=512m
注:在观察内存的使用情况时首先保证相关的线条不是持续增长的,需要有 对应SO、S1区,Eden,old以及Perm和cache
回收的动作出现,并且可以估计其回收的内存大小,如果回收始终没有增长的多,特别是内存增长很多的情况,这时系统很可能存在内存泄露。这时我们可能需要通过其他的更详细的工具对系统的类及内存进行分析,如JMap等。

 

 

例如

监控线程

通过线程的监控可以查看系统中所有的线程数,同时可以点击单个的线程查看具体的线程运行情况,如: 可以结合windows命令netstat –na查看是否有CLOSE_WAIT的状态,有的话可以直接通过线程找到是否有对应的这个状态,这样就可以查出具体是什么线程存在泄露的情况。

 

 

的地址替换成

本文由必威发布于必威-运维,转载请注明出处:能够对整个集群有一个比较详细的状态监控,如

相关阅读